Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
Date: Tue, 28 Jan 2020 21:30:58 +0100
Hi Daniel,
On Tue, Jan 28, 2020 at 5:40 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 28 Jan 2020, Mischa Salle wrote:
> > Just for information, I ran into the same problem when trying to add both
> > Basic and Bearer Authorization headers for an OAuth2 request.
>
> The same issue, really? You seem to be talking about *sending* two
> www-authorization headers while Michel mentioned *receiving* more than one
> authentication method in a single header.
Oops, I was too quick (doing too many things at the same time), you're
totally right of course...
> > I actually there also had the problem that --oauth2-bearer actually
> > doesn't work for https.
>
> This then sounds like a third issue. How doesn't it work? This sounds like an
> issue nobody has told us about.
Actually, I thought it was documented behaviour (although frustrating)
to only support mail protocols, not http(s), which is why I never
reported it:
https://github.com/curl/curl/blob/master/docs/cmdline-opts/oauth2-bearer.d#L4
conform also the manpage of curl. But now I found
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_XOAUTH2_BEARER.3#L32
which pointed me to https://github.com/curl/curl/pull/2102, i.e. since
7.61 this should have been fixed and indeed I've just confirmed that a
master (7.69-dev) indeed sets the Authorization: Bearer header,
although it indeed doesn't work in combination with a --user. (it does
say "* Server auth using Bearer with user 'client'" but does not
actually do anything with the user).
My OpenSUSE still comes with a 7.60, hence I hadn't seen it working.
In short, it's primarily a documentation issue with the manpage of
curl itself, no longer a code issue.
> > Specifying both a --user client_id:client_secret and a -H "Authorization:
> > Bearer myfirstbearertoken" only sends the latter it seems.
>
> curl will only send one Authorization: header, that is true. I've never seen
> or been told a use case before where someone needed more than one.
I agree it's a bit of an edge case, since most OAuth2 authorization
servers will prefer - or at least allow - you to use POST parameters
instead of authorization headers, but I've seen servers where it was
needed (and there are several flows where the client needs to send
both its client_id and secret *and* a token to the server, but most
allow either of them via e.g. POST parameters instead).
Best wishes,
Mischa
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-01-28