Aktuell nutze ich Tinyauth.app [1] für die Forward-Authentifizierung mit einem Caddyserver [2] als Reverse Proxy vor einem Docker Swarm [3]. Das funktioniert auch schon fast wie gewünscht. Beim Testen einer frisch ausgerollten Webapp mit curl(1) ist mit allerdings etwas aufgefallen, auf das ich mir keinen Reim machen kann. Ein Request auf die Webapp ohne Session-Cookie liefert den HTTP-Statuscode 401 "Unauthorized" mit dem Header "X-Tinyauth-Location" und als Wert den URL zur Loginseite. HTTP-Redirects mit den Statuscodes 30x und "Location"-Header sind mir bekannt, aber ein so merkwürdiger "X-<Applikation>-Location"-Header in einem HTTP 401 "Unauthorized" ist mir noch nicht begegnet. Auch im Mozilla Developer Network, bei Selfhtml und anderweitig im Netz habe ich nichts darüber gefunden. Meine Webbrowser führen aber trotz dieser seltsamen Konstellation den gewünschten Redirect auf die Loginseite aus. Besonders befremdlich ist auch, daß zwar der HTTP-Spezifikation zufolge zum Statuscode 401 ein "WWW-Authenticate"-Header gehören müßte, der jedoch ebenso wie der normale Location-Header fehlt. Hat einer der Anwesenden so etwas schon einmal gesehen, möglicherweise sogar Informationen dazu, oder kluge Vermutungen? Hätte jemand einen Link auf eine gute Spezifikation oder Dokumentation zu ForwardAuth? Vielen Dank im Voraus! [1] https://tinyauth.app/ [2] https://caddyserver.com/ [3] https://docs.docker.com/engine/swarm/
Bekommt denn der normale Webbrowser auch diesen 401 Returncode? Oder bekommt den z.B. nur ein Javascript, welches innerhalb des Browsers läuft? Ich würde vorschlagen mal genau zu verfolgen was da bei einem normalen Browser bei so einem Zugriff passiert. Also Firefox, alle Cookies+Cache leeren, Menü Web Developer Tools, Network. Dann den Zugriff versuchen.
Ein T. schrieb: > Meine Webbrowser führen aber trotz dieser seltsamen Konstellation den > gewünschten Redirect auf die Loginseite aus. Steckt im ausgelieferten Dokument evtl. ein Redirect per Javascript oder Meta-Refresh? Ein T. schrieb: > Hat einer der Anwesenden so etwas schon einmal gesehen, möglicherweise > sogar Informationen dazu, oder kluge Vermutungen? Laut Doku sollte der Browser das nicht so ausgeliefert bekommen: https://tinyauth.app/docs/reference/headers/#x-tinyauth-location Klingt danach, dass Deine Requests als API-Requests verarbeitet werden.
Gerd E. schrieb: > Bekommt denn der normale Webbrowser auch diesen 401 Returncode? Der bekommt -- wie curl(1) -- im Body nur ein JSON-Objekt
1 | {"message":"Unauthorized","status":401}
|
Spannend: der Feuerfuchs bekommt einen "location"-Header -- mit HTTP/2, daher die Kleinschreibung. Einen Body zeigt der Firefox nicht an, weil Redirect, da werde ich morgen mal weiter schauen. Sniffen ist leider nicht so einfach, das läuft natürlich alles über HTTPS... > Ich würde vorschlagen mal genau zu verfolgen was da bei einem normalen > Browser bei so einem Zugriff passiert. Also Firefox, alle Cookies+Cache > leeren, Menü Web Developer Tools, Network. Dann den Zugriff versuchen. Naja, die Veranstaltung macht ja, was sie soll, aber ich möchte eben gerne verstehen, warum sie funktioniert. Okay, vielen Dank für Eure Antworten, aber ich muß jetzt mal ins Bettchen. Lieben Dank und bis morgen! :-)
Ein T. schrieb: > Gerd E. schrieb: >> Bekommt denn der normale Webbrowser auch diesen 401 Returncode? > > Der bekommt -- wie curl(1) -- im Body nur ein JSON-Objekt > >
1 | > {"message":"Unauthorized","status":401}
|
2 | > |
Kommt die 401 wirklich als HTTP Staus Response Code oder steht die nur so in diesem JSON drin? Ein zusätzlicher Location-Header sollte bei einem echten 401 eigentlich ignoriert werden. > Sniffen ist leider > nicht so einfach, das läuft natürlich alles über HTTPS... Klar. Deswegen ja die Web Developer Tools. Wobei echtes Sniffen und Decodieren mit Wireshark auch geht wenn man SSLKEYLOGFILE verwendet: https://medium.com/@eremeykin/how-to-decrypt-https-in-wireshark-using-sslkeylogfile-6c09de561233
Gerd E. schrieb: > Kommt die 401 wirklich als HTTP Staus Response Code oder steht die nur > so in diesem JSON drin? Wenn ich nicht zwischen HTTP-Statuscode und -Body unterscheiden könnte, würde es diesen Thread wohl nicht geben. :-) > Ein zusätzlicher Location-Header sollte bei einem echten 401 eigentlich > ignoriert werden. Das hätte ich auch vermutet, aber... es ist ja kein richtiger Location-Header, sondern der Name ist "X-Tinyauth-Location" (bzw. kleingeschrieben in HTTP/2), was das Ganze noch mysteriöser macht. Aaaber: laut Developer Tools gibt Caddy dem Firefox einen HTTP 307 mit korrektem Location-Header. Hm. Es wird also was mit den Request-Headern zu tun haben, würde ich vermuten. > Wobei echtes Sniffen und Decodieren mit Wireshark auch geht wenn man > SSLKEYLOGFILE verwendet: > https://medium.com/@eremeykin/how-to-decrypt-https-in-wireshark-using-sslkeylogfile-6c09de561233 Lieben Dank, das kenne ich, aber... ist halt immer Gefummel.
Ein T. schrieb: > Aaaber: laut Developer Tools gibt Caddy dem Firefox einen HTTP 307 mit > korrektem Location-Header. Weil Caddy damit umgehen kann und daraus für den Client einen üblichen Redirect macht, siehe obiger Link. Seltsam wäre es nur gewesen, wenn das an den Browser rausgegangen wäre und trotzdem funktioniert hätte.
Hmmm schrieb: > Ein T. schrieb: >> Aaaber: laut Developer Tools gibt Caddy dem Firefox einen HTTP 307 mit >> korrektem Location-Header. > > Weil Caddy damit umgehen kann und daraus für den Client einen üblichen > Redirect macht, siehe obiger Link. Hm, und dann kann Caddy damit umgehen, wenn der Firefox anfragt, aber nicht, wenn curl(1) das tut? Seltsam. Der Link bezieht sich auch nur auf Nginx. Den benutze ich aber gar nicht und verwende für die ForwardAuth den URL /api/auth/caddy". Tinyauth sollte daher wissen, daß kein Nginx im Spiel ist, und entsprechende Workarounds dafür gar nicht notwendig sind. > Seltsam wäre es nur gewesen, wenn das an den Browser rausgegangen wäre > und trotzdem funktioniert hätte. Naja, es geht an curl(1) 'raus, und damit also an eine Art Browser, während der Firefox korrekterweise einen Redirect bekommt. Das irritiert mich ja so.
Ein T. schrieb: > Naja, es geht an curl(1) 'raus, und damit also an eine Art Browser, > während der Firefox korrekterweise einen Redirect bekommt. Das irritiert > mich ja so. Eine Erkennung anhand des User-Agent-Headers wäre jetzt nicht allzu ungewöhnlich. Was Du mal machen kannst: Nimm die Ausgabe des Requests aus den Web Developer Tools (siehe oben). Dann baue davon Header für Header exakt in curl nach (Option --header) und schau was passiert.
Ein T. schrieb: > Hm, und dann kann Caddy damit umgehen, wenn der Firefox anfragt, aber > nicht, wenn curl(1) das tut? Seltsam. Achso, der curl-Request ging auch an Caddy, nicht direkt an den Server dahinter? Dann ist das in der Tat seltsam. Hast Du die Caddy-Config selbst gebaut, oder steckt da evtl. eine Ausnahme für Debugging-Zwecke drin, die alles 1:1 durchreicht?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.