Is your feature request related to a problem?
See #6908 for discussion with @Dreamsorcerer
We are have a continuously running service that makes HTTP requests using aiohttp's client. These requests are sent with a bearer token in the authorization header. This token needs to be refreshed from time to time.
Therefore we cannot set the header on the client object. We need to evaluate the header prior to making individual requests. This is cumbersome for an app developer.
Describe the solution you'd like
We would like to configure the client with the required data which can be used at each request to populate an authorization header. In its simplest form, this could be a simple co-routine that evaluates a token cache, generates a new token if required, and populate the header as required.
For the avoidance of doubt, the proposal is for wherever aiohttp supports an auth argument (client session, request), it would support the "enhanced" auth handler.
Currently, aiohttp supports a BasicAuth object which is a customized namedtuple (fields: username, password) with an encode method which returns the base64 encoded header value. Runtime checks are performed ensuring the auth value is an instance of that class.
TODO: expand on preferred optionSee options in comment below.
Describe alternatives you've considered
Both the requests library and the httpx library have similar functionality. For reference:
The httpx approach supports a more defined base class/interface for an auth handler, whereas requests just requires a callable. Fundamentally they do the same thing and inject an authorization header in the request headers.
Related component
Client
Additional context
I am probably able to contribute a PR with an implementation, depending on the agreed scope of the changes.
Code of Conduct
Is your feature request related to a problem?
See #6908 for discussion with @Dreamsorcerer
We are have a continuously running service that makes HTTP requests using
aiohttp's client. These requests are sent with a bearer token in the authorization header. This token needs to be refreshed from time to time.Therefore we cannot set the header on the client object. We need to evaluate the header prior to making individual requests. This is cumbersome for an app developer.
Describe the solution you'd like
We would like to configure the client with the required data which can be used at each request to populate an authorization header. In its simplest form, this could be a simple co-routine that evaluates a token cache, generates a new token if required, and populate the header as required.
For the avoidance of doubt, the proposal is for wherever
aiohttpsupports anauthargument (client session, request), it would support the "enhanced" auth handler.Currently,
aiohttpsupports aBasicAuthobject which is a customized namedtuple (fields: username, password) with anencodemethod which returns the base64 encoded header value. Runtime checks are performed ensuring theauthvalue is an instance of that class.TODO: expand on preferred optionSee options in comment below.Describe alternatives you've considered
Both the
requestslibrary and thehttpxlibrary have similar functionality. For reference:The
httpxapproach supports a more defined base class/interface for an auth handler, whereasrequestsjust requires a callable. Fundamentally they do the same thing and inject an authorization header in the request headers.Related component
Client
Additional context
I am probably able to contribute a PR with an implementation, depending on the agreed scope of the changes.
Code of Conduct