Construct [Proxy-]Authorization headers from username:password section of URLs

[sethmlarson]

We already support this behavior for SOCKS proxies, we should support it in general.

Currently we simply drop this information on the floor for both URLs and HTTP[S] proxy URLs. Might be nice to add support for this in v2. We can error out if both Authorization or Proxy-Authorization are given and they don't match for the same request to be extra safe.

[hramezani]

@sethmlarson I have some questions:

We already support this behavior for SOCKS proxies, we should support it in general.

Do you mean username/password extraction from URL here:

https://github.com/urllib3/urllib3/blob/3a815144ba9822b2981d3300833ae553d6d22a78/src/urllib3/contrib/socks.py#L173-L178

and add them to connection_pool_kw["_socks_options"]?

Currently we simply drop this information on the floor for both URLs and HTTP[S] proxy URLs. Might be nice to add support for this in v2.

Do we want to implement it for ProxyManager?

We can error out if both Authorization or Proxy-Authorization are given and they don't match for the same request to be extra safe.

Does it mean that we have to extract username/password from url and check them with headers in __init__?

[sigmavirus24]

@sethmlarson so I'm not exactly a fan of just doing things for users without their permission. I get this is probably the "smart" thing to do, but i tmakes it hard to factor/maintain later and will probably end up embedding this in the wrong place.

Thinking of v2, I'm wondering if there needs to be some kind of way of specifying authentication strategies (yes, plural) with a high-ish level object. If you're familiar with requests, there's a way of creating a subclass of AuthBase and building logic there which allows you to (for a session or for an individual call) specify a single "Auth" class to handle that request and any redirects that are followed (depending on security context).

There's also a probably not ideal hack towards something like this for Requests: https://toolbelt.readthedocs.io/en/latest/authentication.html but I do think this begs a few questions:

• Do we want to give people "strategies" to provide/handle authentication such that one of the default strategies might be to parse from the URL if present?
• Do we want people to have multiple strategies (if one fails, fall back on the others)?
• Do we want to give people the ability to register strategies per domain?

To be clear, i think we could provide a strategy manager without forcing per-domain to start with. I will say, I don't recall having received bug reports about the hacks I wrote in the Montreal airport but I don't know if that means no one uses it.

[jakermx]

MSFT SingleSign On uses a cookie for this Request, among someother stuff, but basically the session manager requieres a token like cookie for this

[CCLDArjun]

@CCLDArjun , this has now a bounty, will you continue with your PR #2870?

@abebeos I thought it had already been ready to merge. I'll resolve the conflicts and continue. Thanks for letting me know