Re: Problem with DIGEST and multiple authorization headers
Date: Mon, 19 Jun 2017 16:29:00 +0200 (CEST)
On Mon, 19 Jun 2017, Daniel Schwarz via curl-library wrote:
> Hi Daniel, thanks for your reply. Is there any workaround we can do to
> achieve a successful digest authentication despite multiple realms (or
> somehow force the api to use a specific realm)? Is there a chance that you
> will fix this in the near future? Alternatively we have to replace the Curl
> API in our Clients unfortunately.
First, it isn't "you" who fix things. It's we, us. We're a team!
If we were to "fix this", we would need to come up with a way we like that
would work and while this subject has been touched upon casually in the past
as well, we have not seen a full fledged proposal from anyone on exactly how
an API for this would work. Once we get somewhere on an API proposal, I think
it will be a good idea to get started on implementing it and then adjust
iteratively until both meet and they work.
The chance that we'd work on multi-realm HTTP auth support in the near future
depends on numerous factors, including how much help you will provide and what
"near future" means to you. Clearly you have a use case for this feature so
you're probably the one of us with the biggest motivation to get this going.
So how would you like such an API to work?
Is there a work-around in the mean time? I don't know. I could possibly
imagine a way where you try to filter off the irrelevant headers from libcurl,
the ones with the realms you don't care about, so that only the interesting
single one is left and thus libcurl works with that. Perhaps we could enhance
to header callback to allow a return value that makes libcurl ignore that
header? That would still means patching the code of course. Right now I can't
think of a good work-around without touching code...
-- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2017-06-19