Requests: Add bearer token to requests.auth?

[richtier]

in request.auth there is HTTPBasicAuth , HTTPProxyAuth, and HTTPDigestAuth, but no HTTPBearerAuth - for bearer authentication.

It would look something like this:

class HTTPBearerAuth(requests.auth.AuthBase):
    def __init__(self, token):
        self.token = token

    def __eq__(self, other):
        return self.token == getattr(other, 'token', None)

    def __ne__(self, other):
        return not self == other

    def __call__(self, r):
        r.headers['Authorization'] = 'Bearer ' + self.token
        return r

Is there a reason to not add bearer auth to the codebase?

[sigmavirus24]

Hi @richtier thanks for opening this.

Is there a reason to not add bearer auth to the codebase?

The main reasons are the following:

1. because Bearer authentication is so terribly simple that it can be implemented as above easily (or even more simply, really)
2. because we're under a fairly strict feature-freeze and this would constitute a break of that freeze
3. this can be easily shipped via the requests-toolbelt for people who don't want to implement this simply

[richtier]

@sigmavirus24 good reasons :+1:

[wowkin2]

@sigmavirus24, yes, it is simple but will be used in many projects. In my experience - it is most popular auth method.

1. But why I need to manually migrate that part of code from project to project and violate DRY principle?
2. Can you add/plan it to the next feature-freeze?
3. As I don't use (and currently don't plan to use) requests-toolbelt - why I should install it, if all similar auth types are in requests?

Thanks in advance.

[sigmavirus24]

In my experience - it is most popular auth method.

Your experience doesn't match mine. Anecdotal data is useless.

Can you add/plan it to the next feature-freeze?

No. This project is in perpetual feature-freeze. There is a high bar for new features, this does not even come close to it.

As I don't use (and currently don't plan to use) requests-toolbelt - why I should install it, if all similar auth types are in requests?

There are 2 auth-types natively supported by Requests:

• HTTP Digest Authentication
• HTTP Basic Authentication

There are a myriad of libraries for other authentication types (oauth, kerberos, ntlm, and so many more). The toolbelt, includes other auth mechanisms that are helpers for more basic concerns.

[sebastian-philipp]

Please reconsider this decision.

It's about having a consistent API and symmetric API.

Like e.g. my thinking was:

1. I need bearer auth
2. let's look at requests.readthedocs.io. Ok understood: authentication looks like requests.get(url, auth=<auth-type>(...))
3. search for Bearer on that page.
4. Search again for Bearer on that page.
5. Last resort: Google: https://www.google.com/search?q=python+requests+bearer
6. tying to understand https://stackoverflow.com/questions/45868120/python-post-request-with-bearer-token?rq=1
7. "why is this so much more complicated????"

Which means, by omitting bearer authentication, cause it is so simple, you in fact made bearer authentication much more complicated than other authentication schemes. Unfortunately.

[sigmavirus24]

Which means, by omitting bearer authentication, cause it is so simple, you in fact made bearer authentication much more complicated than other authentication schemes.

I guess that makes OAuth impossible? This logic makes no sense. BasicAuth and DigestAuth are the two most common auth types (or were over 10 years ago). Given that most of the auth handlers just update headers and you can do that yourself here, I don't understand why this is more complicated to you. The toolbelt exists for just such "dead-simple and borderline popular" options so that folks don't have to reimplement it themselves but no one has sent an implementation and I don't care enough to do it myself.

Also, the library is in feature-freeze. So new features are not accepted no matter how complicated you think this is or how common one person thinks this is.

If you want a library that will accept any old feature request without regard to the long-term quality of the software itself, it's maintainability, or the effect all of that has on the maintainer(s) still working on the project, maybe find a different HTTP client. There's tonnes at this point, some might even be of better quality.

I no longer represent this project though, so take all of this for whatever little you already value my opinion (given that you have thumbs-downed my comments for explaining rationale and thought it was appropriate to revive an issue that's been closed and dormant for 2 years).

[sebastian-philipp]

Which means, by omitting bearer authentication, cause it is so simple, you in fact made bearer authentication much more complicated than other authentication schemes.

I guess that makes OAuth impossible? This logic makes no sense. BasicAuth and DigestAuth are the two most common auth types (or were over 10 years ago). Given that most of the auth handlers just update headers and you can do that yourself here, I don't understand why this is more complicated to you.

I'm not talking about the complexity of the authentication mechanism, but of the python API here. By that I think using OAuth is easier that Bearer for inexperienced users right now.

The toolbelt exists for just such "dead-simple and borderline popular" options so that folks don't have to reimplement it themselves but no one has sent an implementation and I don't care enough to do it myself.

Thank you for the hint!

Also, the library is in feature-freeze. So new features are not accepted no matter how complicated you think this is or how common one person thinks this is.

That's indeed unfortunate.

If you want a library that will accept any old feature request without regard to the long-term quality of the software itself, it's maintainability, or the effect all of that has on the maintainer(s) still working on the project, maybe find a different HTTP client. There's tonnes at this point, some might even be of better quality.

I no longer represent this project though, so take all of this for whatever little you already value my opinion

Well. Obviously, my intention was not to offend you, but provide some input why I think Bearer should be reconsidered.

... thought it was appropriate to revive an issue that's been closed and dormant for 2 years.

I for one would not be offend by someone commenting on older issues.