HURRAH ! - the latest snapshot works! Thank you so much for your perseverence. Appreciating it greatly.
Cordial greetings,Hans-Jürgen PS: For the archives, here an example of a successful message: Authorization:Digest username="foofoo",realm="traveltainment",nonce="1424706916778:b0b315b599103981f04ac9b80f3d5aab",uri="/TTXml-1.6/Dispatcher/Search/Package/RegionList",qop=auth,nc=00000001,cnonce="ae3e9ce08d9c2cfcce47b857ad764b9e",response="6e60b601cd1a2590c637889b1d7f61cb",algorithm=MD5,opaque="pcyalPBREdBtyQHIHRxOQPgGANZiOjeW"
Christian Grün christian.gruen@gmail.com schrieb am 14:14 Montag, 23.Februar 2015:
Hi Hans-Jürgen,
- the missing "=" between "opaque" and its value
Oh, that's a clear bug. Thanks.
- added quotes around the qop value, which are absent in the successful
variant (JMeter).
I looked up the RFCs again, and it was surprised by three things:
1. It seems that the qop value must not be enclosed in quotes in the client request; but it needs to be quoted in the server response. Wow. 2. I also noticed that the algorithm value is not allowed to be quoted either. JMeter, however, uses quotes. I have decided to drop them. 3. I also noticed that the spec does not expect URI values to be quoted (see the "digest-uri" rule below). However, all examples I found use quotes, so I sticked with the existing solution.
RFC 2617, 3.2.1 (HTTP Authentication; Response): digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token
RFC 2617, 3.2.2 (HTTP Authentication; Request): digest-response = 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 message-qop = "qop" "=" qop-value
RFC 2616, 5.1.2 (HTTP/1.1; Request-URI): Request-URI = "*" | absoluteURI | abs_path | authority
Let's see if we'll be more successful following the spec or its implementations.. Could you please check out the latest snapshot [1]? If the problem persists, feel free to take this offline (the WireShark clips have ben very useful).
Christian
[1] http://files.basex.org/releases/latest
For comparison, here once more a successful message as
sent by JMeter:
Authorization: Digest username="foofoo", realm="traveltainment", nonce="1424682817758:7c9e417b9b2852c11d49ccf69eccd267", uri="/TTXml-1.6/Dispatcher/Search/Package/RegionList", response="95d43c7e14b18e9414391ecf1d86a352", qop=auth, nc=00000001, cnonce="ce4d392fb3233de7", algorithm="MD5", opaque="pcyalPBREdBtyQHIHRxOQPgGANZiOjeW"
Cordial greetings from Hans-Juergen
PS: If the problem is not caused by the "opaque" header, it might depend on Java 7 vs. 8. I am using Java 8.
The changelog remarks on Digest Authentication ( http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.... )
Quotation: In previous releases, the HttpURLConnection Digest Authentication implementation incorrectly quoted some values in the WWW-Authenticate Response Header. In the Java SE 8 release, these values are no longer quoted. This is in strict conformance with the RFC 2617, HTTP Authentication: Basic and Digest Access Authentication. Certain versions of some server implementations are known to expect the values to be quoted. HTTP requests to these servers might no longer successfully authenticate. Other server implementations that previously failed to authenticate because the values were quoted, might now successfully authenticate.
Christian Grün christian.gruen@gmail.com schrieb am 19:17 Freitag, 20.Februar 2015:
Yet another update: I added the missing quotes in the client request. It didn't make a difference with the browsers I tried, but it might make a difference with other applications..
The new snapshot [1] is available since appr. four seconds, Christian
[1] http://files.basex.org/releases/latest/
On Fri, Feb 20, 2015 at 6:43 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Hans-Jürgen,
Thanks for the in-depth feedback on our client-side digest authentication. I have now included the algorithm in the client request (I thought the value was optional [1], but this may well be wrong). The length of the cnonce string shouldn't matter (..I think..).
Could you please try the latest snapshot [2] and see if your server accepts the sent requests? If it doesn't, it may be the missing quotes..
Thanks in advance! Christian
[1] http://en.wikipedia.org/wiki/Digest_access_authentication#Overview [2] http://files.basex.org/releases/latest
On Fri, Feb 20, 2015 at 5:40 PM, Hans-Juergen Rennau hrennau@yahoo.de wrote:
Dear BaseX team,
I have problems to get the http:send-request going when using Digest authentication. I get a response as if the password were wrong, although I think it isn't.
Request: <http:request method='post' send-authorization='true' username='foofoo' password='secret' auth-method="Digest"> <http:body media-type='text/xml' method='xml'>{$useMsg}</http:body> </http:request>
Response: <http:response xmlns:http="http://expath.org/ns/http-client" status="401" message="Unauthorized"> <http:header name="Server" value="Apache/2.2.22 (Ubuntu)"/> <http:header name="WWW-Authenticate" value="Digest realm="traveltainment", qop="auth", nonce="1424448664077:8d932e72fb644113f4fb1a76f942cf1d", opaque="pcyalPBREdBtyQHIHRxOQPgGANZiOjeW""/> <http:header name="Connection" value="close"/> <http:header name="Vary" value="Accept-Encoding"/> <http:header name="Content-Length" value="954"/> <http:header name="Date" value="Fri, 20 Feb 2015 16:11:04 GMT"/> <http:header name="Content-Type" value="text/html;charset=utf-8"/> </http:response>
Interestingly, a JMeter test using the same URL, user name and password works correctly. (I used copy & paste to transfer the credentials from the JMeter GUI into the XQuery code, and the credentials are just what some documentation tells me; tried of course also typing them in manually.)
Using WireShark, I observed the messages sent by JMeter and BaseX, respectively. BaseX does send two requests, as it is supposed to do; but the authorization data sent by the second one are in two respects different from the data sent by JMeter: JMeter sends a field: algorithm="MD5", which BaseX does not, and the cnonce is much longer. (See below for the authorization strings.)
I use Java 8, and I suspect the problem is connected with that. I heard rumours that Digest authentication with Java 8 might require a little adaptation of the code. Did you try the module using Java8?
Cheers, Hans-Juergen
PS: (1) Authentication sent by BaseX, failing:
User-Agent: Java/1.8.0_31
Authorization: Digest username=foofoo, realm=traveltainment, nonce=1424448664069:b6ed9add48830631ae90ad27cfcb5c5e, uri=/TTXml-1.6/Dispatcher/Search/Package/RegionList, qop=auth, nc=00000001, cnonce=9b2ff1ce6900217dd6be667aa6f99e12, response=4e35b40dd4ba7d62cd6123d9adebc046, opaque=pcyalPBREdBtyQHIHRxOQPgGANZiOjeW
Authorization: Digest username=foofoo, realm=traveltainment, nonce=1424449896135:5fa18cec34de1a15d8ce2a36df77bd6a, uri=/TTXml-1.6/Dispatcher/Search/Package/RegionList, qop=auth, nc=00000001, cnonce=5be8fce766d843e8ea29936b73ed94c7, response=3757d8fb6cfc4c997030541c58e72d61, opaque=pcyalPBREdBtyQHIHRxOQPgGANZiOjeW
(2) Authentication sent by JMeter, successfully (please note the "algorithm" field; also note the much shorter cnonce):
User-Agent: Apache-HttpClient/4.2.6 (java 1.5)
Autorization: Digest username="foofoo", realm="traveltainment", nonce="1424448476861:032a9011541d271a429d737844ec860a", uri="/TTXml-1.6/Dispatcher/Search/Package/RegionList", response="df6416855e49a0f28cff8020c30ad3a7", qop=auth, nc=00000001, cnonce="c4b43ae817866fb5", algorithm="MD5", opaque="pcyalPBREdBtyQHIHRxOQPgGANZiOjeW"
Authorization: Digest username="foofoo", realm="traveltainment", nonce="1424450034667:82c9d9977a208442a7926a948e163e45", uri="/TTXml-1.6/Dispatcher/Search/Package/RegionList", response="74712ad74209c954bfb6e545b5f8670b", qop=auth, nc=00000001, cnonce="788dbfb1ed7a77ef", algorithm="MD5", opaque="pcyalPBREdBtyQHIHRxOQPgGANZiOjeW"