![]() |
401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Hallöle,
ich muss einen REST-Service mit D7 ansprechen (es muss leider D7 sein, da komme ich nicht drum herum, habe ich mir nicht ausgesucht). Es ist keine Authentifizierung erforderlich, und mit dem Postman bekomme ich auch ein Ergebnis, jedoch mit Delphi nicht. Ich verwende die Indy10-Komponenten. Folgendes ist die Prozedur, mit der ich versuche den REST-Service anzusprechen:
Delphi-Quellcode:
Ok, das ist nur ein Testprogramm, daher habe ich alles in den Click-Handler gepackt, aber das ist auch nicht das Problem.
procedure TfrmMain.btnListClick(Sender: TObject);
var ComObj: TWEBComm; IdHTTP: TIdHTTP; URL: String; AuthorizationString: String; Response: TStringStream; begin try URL := 'https://<großes Geheimnis>'; AuthorizationString := '<großes Geheimnis>'; ComObj := TWEBComm.Create; // Interne Komponente IdHTTP := TIdHTTP.Create; Response := TStringStream.Create(''); with ComObj do begin with IdHTTP do begin ConnectTimeout := 5000; ReadTimeout := 10000; HTTPOptions := []; Request.CustomHeaders.Text := 'x-token: ' + AuthorizationString; end; Create_HTTPS(IdHTTP); // Internes Gedönse if sConMsg = 'OK' then begin try IdHTTP.Get(URL, Response); // Hier kriege ich einen 401 Unauthorized memoJson.Text := Response.DataString; except on e: Exception do begin ShowMessage('Fehler in IdHTTP: '#13#10 + e.Message); end; end; end else begin // Fehler... ShowMessage('Fehler in ComObj: ' + sConMsg); end; end; finally FreeAndNil(Response); FreeAndNil(IdHTTP); FreeAndNil(ComObj); end; end; Das interne Gedönse ist nicht das Problem, da ich beim Aufruf eines anderen Endpunktes des gleichen Servers keinen 401 kriege, sondern alles glatt läuft. Also sorry für eventuelles Chaos. Meine Frage lässt sich glaube ich ugf. so zusammenfassen: Ich kann den fraglichen REST-Endpunkt mit dem Postman problemlos ansprechen - mit Delphi leider nicht. Warum? Ich kriege im Delphi einen 401, im Postman aber nicht, und eine Authentifizierung ist am Service auch nicht erforderlich. Das x-token in den CustomHeaders ist korrekt, im Postman wie im Delphi - daran liegt es nicht. Das wird auch nicht vom Webserver ausgewertet sondern vom dem Service dahinter - der 401 kommt aber vom Webserver. Ich habe mal die Indy-Unit durchdebuggt, um die RawHeaders auszulesen, und da stand nur folgendes drin:
Code:
Der Postman schickt folgende Header:
Host: api.glasmatic-services.net
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/3.0 (compatible; Indy Library)
Code:
Tja :(
Cache-Control: no-cache
Postman-Token: <calculated when request is sent> Host: <calculated when request is sent> User-Agent: PostmanRuntime/7.26.8 Accept: */* Accept-Encodig: gzip, deflate, br Connection: keep-alive x-token: <großes Geheimnis> Über jeden Hinweis dankbar verbleibt Caps |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Ändere bitte mal den
Delphi-Quellcode:
in was neueres, z. B.
User-Agent: Mozilla/3.0 (compatible; Indy Library)
Delphi-Quellcode:
ab, etliche Server lehnen eine Unterhaltung mit sowas "altem" ab.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Oder suche Dir hier ![]() Der Originaluseragent von Indy aus Delphi 7 klappt eigentlich nirgendwo mehr so richtig. |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Das hat leider nicht geholfen, ich kriege den Fehler immernoch.
Was könnte es sonst noch sein? Grüße! |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Du nutzt HTTPS, wo wird denn der TIdSSLIOHandlerSocketOpenSSL an idHTTP.IOHandler zugewiesen? Und wie ist er konfiguriert?
|
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Du sagst zwar, das es angeblich nicht an dem x-token Header liegen, aber das einzige was an dem Request rein offensichtlich mit Authentication zu tun hat ist eben genau der Authentication-Token in dem Header.
Postman schickt den mit und kommt durch, bei der Ausgabe der Raw-Headers von Delphi steht der Header auch nicht drin. Von daher würde ich jetzt zu allererst mal Fiddler als Debug-Proxy dazwischen klemmen und schauen, ob der Header a) wirklich nicht mit kommt - und nicht lediglich nur nicht ausgegeben wird - und wenn das wirklich der Fall ist dass der Header fehlt, dann b) schauen warum er fehlt und wie man in c) rein bekommt. Oder ein noch einfacherer Gegentest: Lass den Header in Postman mal weg. Ich würde darauf setzen Du bekommst den gleichen 401er wie Delphi auch. |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Danke für die Antwort!
Test: ich habe im Postman den x-token weggelassen, kriege aber nicht den 401, sondern der Webserver akzeptiert den Request, und der dahinterliegende Service liefert eine JSON-Antwort:
Code:
Grüße!
{
"error": "A token is required" } |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Macht der Postman vielleicht ein POST bzw. ist das wichtig? Viele APIs erlauben nur die jeweils richtige Methode (POST, GET, PUT, DELETE, ...)
Du machst ja ein GET: Zitat:
Möglicher Fix: IdHTTP.Request.Accept := '*/*'; |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Hallo,
nein, im Postman habe ich auch GET als Methode ausgewählt. Content-Type JSON hatte ich früher schon, hab es nochmals ausprobiert, bringt leider keine Änderung. |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Habe gerade jemanden aus dem Urlaub geholt, der den Server debuggt.
Er sagt der Header "x-token" würde nicht übermittelt werden. Mache ich irgendwas falsch mit der Einbindung der "CustomHeaders"? |
AW: 401 Unauthorized - jedoch eigentlich keine Athentifizierung erforderlich
Ich glaube du musst bei Indy = als Trennzeichen verwenden. Am besten verwendest du direkt AddValue.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz