thoughts on async implementation about httpx_auth

[Colin-b]

Hello @rafalkrupinski
I am currently looking at finally introducing async coverage in the test suite. It requires some refactoring of the test suite, I'll keep you posted, once it's done I will consider reviewing your suggestions and the PR that is opened for quite some time already on this.

Thanks a lot for your patience

[rafalkrupinski]

I've just pushed a commit that removes the inner Client from Auth classes - https://github.com/python-lapidary/httpx_auth_async/tree/feature/async. If you like the direction I can separate the flows to sync and async versions.

edit:
The implementation itroduces meta-auth - using Auth object to authenticate auth flow requests. In other words, when Auth object needs to make authenticated request to the auth server, another auth object is used.

Because of that, and because auth flows need to read responses (which may be either sync or async), there isn't that much of implementation to share between a/sync versions.

It's possible that I know OAuth2 too little, and a simpler implementation is possible, e.g. if only HTTP Basic authentication is ever used, it could be simply done in the OAuth class, without using meta-auth.

Cheers

[Colin-b]

The test suite is now ensuring non regression on async flows as well. Feel free to submit small scale focused PRs and I will gladly review.

The client is a parameter that is necessary because some users might have rules that requires specific proxy settings, certificates or whatever and this is not the goal of this package to reproduce every feature httpx offers to cover those cases, so we delegate to the user, the responsibility to provide a properly configured client in case they need to.

[rafalkrupinski]

Is it something mounts can't handle?

[Colin-b]

I am not sure to follow, if the client has custom rules to achieve auth and an additional set of rules to reach the authenticated endpoint, how would you do it without providing N parameters to every auth class that would need to be forwarded to the inner client of the auth class? Let's say your certificate differs and your proxy differs (mounts can cover proxy on client side, but not certificate). And this is only an example I can think of, I am sure we would have to cover a whole lot of use cases, corporate networks are a nightmare ;)

[rafalkrupinski]

if the client has custom rules to achieve auth and an additional set of rules to reach the authenticated endpoint, how would you do it without providing N parameters to every auth

How large is N? Cookies, headers, query params, body... perhaps a single parameter request_args: dict?
Proxy and cert should be handled by mounts...

mounts can cover proxy on client side, but not certificate

This doesn't work?

httpx.AsyncClient(mounts={'https://example.com', httpx.AsyncHTTPTransport(verify=ssl.SSLContext(...) or cert=...)})

And this is only an example I can think of, I am sure we would have to cover a whole lot of use cases, corporate networks are a nightmare ;)

Would be a great help if I knew some corner cases.

[Colin-b]

You are right, I guess it's possible to do everything via mounts, though you would admit it's not as straightforward to provide for a client.
Anyway I will gladly review your proposal on async. If you could come up with the smallest possible enhancements that would help the review and increase the chances for it to get merged.

Thanks again !