Digest Access Authentication

Hallo zusammen,

ich versuche gerade Bestände über eine API abzufragen, das sollte hier, da Username und PW vorhanden und eine CSV zurückgegeben wird, eigentlich einfach sein.

Leider ist de Authentifizierung nicht erfolgreich, was muss ich denn einstellen wenn der Lieferant angibt dass eine Digest Access Authentication verwendet wird. Methode zum Abruf ist Post.


Danke und Grüße

Enrico

Da wird Username und Passwort nochmal extra durch eine Hash-Funktion wie MD5 geschleust (siehe Beispiel)

Hallo zusammen,


ich komme hier nicht weiter. Wenn ich mir das wie im Beispiel zusammenbaue sieht das etwa so aus:


<#assign HA1 = md5("BENUTZER:HOST_OHNE_ZIELPFAD:PASSWORT")!>
<#assign HA2 = md5("GET:ZIELPFAD")!>


dann nehme ich die beiden Ergebnisse und versuche Sie in der Response zusammenzubauen:


${HA1}
${HA2}


<#assign response = md5("b52aa58e376606bf2558419e9acb35c6:+Upgraded+v110cf18c6d11aa9fe1fde21f16b2f4d80f062f134e322d70109eecc67c3bd9ed34cf59f990ca8cba7f5f6acda82ddb56e88b7ca05db4d3452:00000001:0a4f113b:auth:606da9e39a30a2429cf5c7348d82dcbc")!>


Trotzdem komme ich da nicht weiter, was mache ich denn falsch? Muss ich eventuell ein anderes nonce und cnonce verwenden? Wenn ja, woher weiß ich welche?


Danke und Grüße

Enrico

Nachtrag: In Postman bekomme ich ein Ergebnis, allerdings nur mit dem Algorithmus MD5-sess.

Hat niemand eine Idee?

Laut https://en.wikipedia.org/wiki/Digest_access_authentication wird bei MD5-sess ja folgendes gemacht:


HA1 = MD5(MD5(username:realm:password):nonce:cnonce)


hast du das auch so nachgebaut?

Hallo Luas, ich habe es im TextHTMLWriter nachgebaut und ie response in den Apcall eingefügt bekomme aber noch immr Unauthorized, ich glaube ihr müsst euch das tatsächlch mal anschauen.


Eventuell liegt es auch am nonce...


Gerne könnt ihr auch im Ticket antworten.


VG

Enrico

Probier mal noch , dass du die Requests mit einem Tool wie z.B. https://hookbin.com/ vergleichst. Vielleicht kommst du ja so dem Unterschied auf die Schliche.

Wurde per Ticket geklärt. Wir haben HTTP Digest Authentication direkt in die HTTP-Accounts eingebaut. Damit sollte diese Authentifizierung auch out-of-the-box funktionieren. Testen kann man das beispielsweise mit [http://httpbin.org/#/Auth/get_digest_auth__qop___user___passwd_](http://httpbin.org/#/Auth/get_digest_auth__qop___user___passwd_) ![image](upload://ZCfNyNiTCBBRvKHI9tyTVbW2ww.png) ![](upload://2BpehohtIxfzJIvg84Mt9fK9RPi.png) ![](upload://v0cKQnNfo0BSTMJBqxiSSv82eNN.png) Ein paar Hintergrundinfos:


Unser intern genutzter HTTP-Client macht dabei das ganze Digest Auth Handling und erkennt dabei automatisch die ganzen Dinge wie qop, nonce, algorith usw. von der Gegenseite. Dieses Digest macht bei der ersten Anfrage auch eigentlich 2 HTTP-Requests im Hintergrund. Im ersten Call wird die Gegenseite angefragt, und die verweigert erstmal mit einem 401 und einem WWW-Authenticate Reponse Header. In diesem Response-Header stehen nonce, der verwendete Algorithmus (z.B. md5 oder md5-sess) usw. drin. Das wertet unser Client aus und macht entsprechend den zweiten verschlüsselten Call. Dieser zweite Request geht dann normal durch, sofern Username und Password korrekt sind.


Hinweis: Beim SpreadsheetURL Download werden aber nicht jedes mal 2 HTTP-Requests gemacht, sondern nur beim ersten mal. D.h. ein SpreadsheetURLDownload der eigentlich 10 Requests machen will, macht bei Digest Auth 11 Requests.