Digest Authentication Middleware for aiohttp#10725
Conversation
This is the initial work by jf from aio-libs#2213, which I rebased onto the tip of master. It is fully brought back to life in subsequent commits.
This completes the implementation of the digest helper, implementing for additional hashing algorithms sha256 and sha512, as well as auth-int qop. It implements tests and documents the features. The DigestAuth feature was shimmed into the existing API so it could be used in place of BasicAuth in the auth field of ClientSession and ClientRequest.
9927632 to
22825c1
Compare
|
We had talked about making a more generic client middleware, but we never moved that forward. I'm inclined to accept this since we would very much like to have digest auth support in 3.x, and move to using client middleware for auth in 4.x since it would be a breaking change anyways. |
CodSpeed Performance ReportMerging #10725 will improve performances by 10.6%Comparing Summary
Benchmarks breakdown
|
I agree with that - I didn't see any other good way of doing this without breaking backward compatibility. Almost requested punting this one to 4.x but it ended up not being horrible for a first attempt. @feus4177 did most of the heavy lifting anyway. |
I was hoping to work on that reasonably soon. This PR would add several extra hooks throughout the code that we'd need to remember to remove again. It'd also be confusing to users if we add this and then deprecate it only a release or 2 later. My current understanding is that the middlewares would not be a breaking change and they could be backported. Then BasicAuth would become deprecated in favour of the middlewares. |
I'd be much happier with client middleware vs this implementation. Seems like that is closer than I expected so I'd probably stop working on this PR but keep it warm in case we run into any snags with client middleware that would prevent it from being available in 3.12. |
|
For clarity: Once we have the client middleware we could add a digest auth client middleware (probably much of this could be reused) |
Okay I am going to put this down for now. I really only picked it up in an effort to move 3.12 along. Feel free to ping me if/when we're ready to pick back up. |
|
We could write a bit better tests if we had server side support for digest auth, but thats likely something we don't need to implement for aiohttp |
|
Thanks @TimMenninger for getting this moving again. I reworked it to use the new client middleware. |
Backport to 3.12: 💚 backport PR created✅ Backport PR branch: Backported as #10894 🤖 @patchback |
Co-authored-by: jf <[email protected]> Co-authored-by: J. Nick Koston <[email protected]> Co-authored-by: J. Nick Koston <[email protected]> Co-authored-by: Sam Bull <[email protected]> (cherry picked from commit ab76c5a)
…for aiohttp (#10894) Co-authored-by: Tim Menninger <[email protected]> Co-authored-by: jf <[email protected]> Co-authored-by: J. Nick Koston <[email protected]> Co-authored-by: J. Nick Koston <[email protected]> Co-authored-by: Sam Bull <[email protected]> closes #2213 closes #4939
What do these changes do?
Implementation Details
This middleware implements RFC 7616.
The implementation fully complies with the RFC specifications, including:
Changes
This PR adds:
DigestAuthMiddlewareclass that handles HTTP Digest AuthenticationAre there changes in behavior for the user?
There are no changes to default behavior. It will continue to use
BasicAuth, and existing uses ofBasicAuthshould be intact.Is it a substantial burden for the maintainers to support this?
no
Related issue number
replaces and closes #2213 closes #4939
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.