Yes, I agree with you. The round-trip in case of 401s is actually not an
efficient way for authentication. Whenever multiple authentication headers
come into place, the user should know which realm to use. So we should
focus on setting one realm directly. In our use cases we always know the
realm before. So it would be completely fine. On client side I would assume
to get the option of setting a specific Realm as an authentication
parameter. I cannot evaluate how it is best to implement in libcurl. The
callback also sounds like a good approach. I could imagine in case of a
failed auth due to a differing realm the client could give a more accurate
feedback to the user.

> Me neither. So we need to make something up that we think should work for
> us in general and your use case in particular.
>

> 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.
>

> 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 realms.
>
> 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
> manner.
>
> What do you think?
>
> --
>
> / daniel.haxx.se
>

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-06-22