Re: Problem with DIGEST and multiple authorization headers
Date: Thu, 22 Jun 2017 10:11:45 +0200 (CEST)
On Wed, 21 Jun 2017, Daniel Schwarz via curl-library wrote:
> I would like to provide my help on this as this issue really blocks us, and
> presumably many others, in using curl for these kind of interfaces. But I am
> also not aware of any standardized approach to handle such multi-realm
> authentication on client side.
Me neither. So we need to make something up that we think should work for us
in general and your use case in particular.
> I have tested these multi-realm digest interfaces with Firefox and Poster
> (Firefox REST Client Addon). It seems to iterate over all given
> Authentication Headers. If an authentication fails, it just takes the next
> realm and so on.
Is that how you'd like it done? Seems a bit crude to me and will cause a lot
of round-trips and 401s if there are many realms.
> Additionally it would be nice to have the option of setting the relevant
> digest auth realm in advance, so that other authentication headers will be
> just ignored.
If you know before-hand of a realm that you'd like then I can certainly see
that you'd like to set which realm to use. But then that also risks that
you've set a realm that won't come and then auth will fail because of that.
Another approach is to collect all offered realms and ask the application with
a callback which of these N realms would you like to use, and then proceed
using that one... Such a callback would then also need to ask for
user/password for that specific realm since they may of course differ between
Maybe its even possible to support both?
I think it is enough to just work on one realm at a time and if that fails
auth, you restart the transfer and select the another auth. I don't think
libcurl itself needs to handle doing auth on multiple realms in some serial
What do you think?
-- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2017-06-22