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

The output of Curl shows that the duplicate digest auth headers are always
ignored:
"* Ignoring duplicate digest auth header."

After the digest auth failure the first authentication header ist marked
with:
"* Authentication problem. Ignoring this."

But the other auth header are also still ignored. Rather it should take the
next of the left auth headers and try again.

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.

Here's an example of the current behaviour (T1Realm would have been the
correct one in this case, but it only takes T3Realm):

> > GET /interface/v1/123xyz HTTP/1.1
> > Host: localhost:12345
> > Accept: */*
> > Accept-Encoding: deflate, gzip
> > Content-Type: text/xml
> > Content-Length: 0
> < HTTP/1.1 401 Unauthorized
> < Date: Thu, 01 Jun 2017 14:11:53 GMT
> < Server: Apache-Coyote/1.1
>
>
>
>
> *< WWW-Authenticate: Digest realm="T3Realm", qop="auth",
> nonce="1496326313805:68288:0cfc3c0f23e7996e6feb35e8bd41adf4",
> opaque="ef65d4342759d9628ddabff7afc1063c"* Ignoring duplicate digest auth
> header.< WWW-Authenticate: Digest realm="T1Realm", qop="auth",
> nonce="1496326313805:60114:2bcbe7b278a310132a9ed5ce748e71e7",
> opaque="ef65d4342759d9628ddabff7afc1063c"* Ignoring duplicate digest auth
> header.< WWW-Authenticate: Digest realm="T2Realm", qop="auth",
> nonce="1496326313807:16957:9bb61017669c9ef504fbdf650a01bad5",
> opaque="ef65d4342759d9628ddabff7afc1063c"*
> < Content-Type: text/xml;charset=UTF-8
> < Content-Length: 92
>
> * Ignoring the response-body
> * Received 92 B chunk
> * Connection #18 to host localhost left intact
> * Issue another request to this URL: '
> http://localhost:12345/interface/v1/123xyz'
> * Found bundle for host localhost: 0x7ff2308714e0
> * Re-using existing connection! (#18) with host localhost
> * Connected to localhost (::1) port 12345 (#18)
> * Server auth using Digest with user '929a0877cb787c21be0502cdfc0e66ee'
> > GET /interface/v1/123xyz HTTP/1.1
> > Host: localhost:12345
> *> Authorization: Digest username="929a0877cb787c21be0502cdfc0e66ee",
> realm="T3Realm",
> nonce="1496326313805:68288:0cfc3c0f23e7996e6feb35e8bd41adf4",
> uri="/interface/v1/123xyz",
> cnonce="ZDRkZTk4NjA2ZmE1N2RjNDg2M2MzMmQ0ZjU2NWI4YTA=", nc=00000001,
> qop=auth, response="56bcd3c94b2c3fb9e891fba34e9b595b",
> opaque="ef65d4342759d9628ddabff7afc1063c"*
> > Accept: */*
> > Accept-Encoding: deflate, gzip
> > Content-Type: text/xml
> > Content-Length: 13158
> | (12.8 KB hidden)
> * upload completely sent off: 13158 out of 13158 bytes
> *< HTTP/1.1 401 Unauthorized*
> < Date: Thu, 01 Jun 2017 14:11:53 GMT
> < Server: Apache-Coyote/1.1
> * Authentication problem. Ignoring this.
> < WWW-Authenticate: Digest realm="T3Realm", qop="auth",
> nonce="1496326313841:45317:b52e0b6ed75010b31a93babf1f0f0ea9",
> opaque="ef65d4342759d9628ddabff7afc1063c"
> * Ignoring duplicate digest auth header.
> < WWW-Authenticate: Digest realm="T1Realm", qop="auth",
> nonce="1496326313842:93869:4383af7bc1ce2bd7daabb0dc8baefee0",
> opaque="ef65d4342759d9628ddabff7afc1063c"
> * Ignoring duplicate digest auth header.
> < WWW-Authenticate: Digest realm="T2Realm", qop="auth",
> nonce="1496326313843:69371:cd39e6d283ade19d1a54d5367e3b2944",
> opaque="ef65d4342759d9628ddabff7afc1063c"
> < Content-Type: text/xml;charset=UTF-8
> < Content-Length: 92
>
> * Received 92 B chunk
> * Connection #18 to host localhost left intact
> * Ignored 0 cookies

2017-06-19 16:29 GMT+02:00 Daniel Stenberg <daniel_at_haxx.se>:

> 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.html
Received on 2017-06-21