Navigieren und auth

[der henry]

Hallo,

eine "Bestandsanlage" hat ein webbasiertes Visualisierungssystem. Wenn der Benutzer das Webinterface benutzen will gibt er eine dyndns-Adresse im Browser ein.

z.B. mydynds/anlage_1

hinter der dyndns-Adresse läuft ein Webserver der pro Anlage nur die "index.html" bereitstellt. In dieser index.html steht ein Frame der auf die "Maschinenwebseiten" verweist ("scr=http:Maschinen_ip")

Somit kann der Benutzer auf der webbasierten Steuerung der entsprechenden Maschine navigieren.

Wenn nun der Benutzer eine Webseite öffnet die im Frame (Framename in der index.html) geöffnet wird, wird nach keinem weiteren login gefragt.

Wird aber eine Webseite geöffnet, die ein eigenen Tab, oder gar ein eigenes Fenster öffnet, so wird erneut ein login am "Maschinenwebserver" benötigt. Wird wieder user/passwort eingegeben gilt die "auth" danach für alle folgenden Webseiten.

Dies war früher bei Firefox nicht so, ich kann leider nicht sagen, seit wann das so ist, die Leute leben einfach damit. Interessanterweise ist dieses "Problem" nur beim Firefox, Chrome fragt kein 2. mal nach der Authentifizierung.

Wie gesagt, das ist ein bestehendes System, hier wird/darf/soll nichts geändert werden. Der Kunde kann damit leben, würde es aber gerne wissen, warum dies sich verändert hat .... mich interessiert es auch ;-)

Ich will es kurz nochmals zeigen

dyndns.ip/Anlage_1 -> index.html (auf dem Webserver für alle Maschinen)

index.html (src://ip_der_Maschine) -> index.html (Webserver auf der jeweiligen Maschine) -> login (auth) -> navigieren auf allen Seiten die im selben Frame laufen -> Aufruf einer Webseite, die nicht im Frame läuft ->

-> Firefox -> erneutes login (auth) -> weiteres navigieren bis zum beenden des Browsers -> Chrome -> sofortiges navigieren, ohne erneutes login (auth) ( so war es früher bei Firefox auch)

Wer hat hier einen Tip.

Gruß der henry

[Der Martin]

Hallo Henry,

Wird aber eine Webseite geöffnet, die ein eigenen Tab, oder gar ein eigenes Fenster öffnet, so wird erneut ein login am "Maschinenwebserver" benötigt. Wird wieder user/passwort eingegeben gilt die "auth" danach für alle folgenden Webseiten.

Dies war früher bei Firefox nicht so

das kann ich gerade nicht nachvollziehen, aber es ist durchaus vorstellbar, dass die Firefox-Enwickler die HTTP-AUTH-Daten seit Version X nicht mehr zwischen zwei Browser-Tabs oder gar -Fenstern hin- und herreichen.

Wer hat hier einen Tip.

Ich vermute, es gibt irgendeine Einstellung in about:config, mit der man dieses neue Verhalten wieder aushebeln kann. Da müsste ich aber auch erst recherchieren.

May the Schwartz be with you
 Martin

[Robert B.]

Moin miteinander,

Wird aber eine Webseite geöffnet, die ein eigenen Tab, oder gar ein eigenes Fenster öffnet, so wird erneut ein login am "Maschinenwebserver" benötigt. Wird wieder user/passwort eingegeben gilt die "auth" danach für alle folgenden Webseiten.

Dies war früher bei Firefox nicht so

das kann ich gerade nicht nachvollziehen, aber es ist durchaus vorstellbar, dass die Firefox-Enwickler die HTTP-AUTH-Daten seit Version X nicht mehr zwischen zwei Browser-Tabs oder gar -Fenstern hin- und herreichen.

Also im aktuellen Firefox unter Windows werden sowohl Cookies als auch HTTP-Basic-Auth weiterhin browserweit verwendet, d.h. in allen Tabs und Fenster – außer natürlich in privaten Fenstern.

Wie tritt das Problem denn genau auf?

Viele Grüße
Robert

[TS]

Hello,

Wird aber eine Webseite geöffnet, die ein eigenen Tab, oder gar ein eigenes Fenster öffnet, so wird erneut ein login am "Maschinenwebserver" benötigt. Wird wieder user/passwort eingegeben gilt die "auth" danach für alle folgenden Webseiten.

Dies war früher bei Firefox nicht so

das kann ich gerade nicht nachvollziehen, aber es ist durchaus vorstellbar, dass die Firefox-Enwickler die HTTP-AUTH-Daten seit Version X nicht mehr zwischen zwei Browser-Tabs oder gar -Fenstern hin- und herreichen.

Also im aktuellen Firefox unter Windows werden sowohl Cookies als auch HTTP-Basic-Auth weiterhin browserweit verwendet, d.h. in allen Tabs und Fenster – außer natürlich in privaten Fenstern.

... aber nur, wenn das Cookie auch zur Request-Domain gehört!

siehe z. B. bei PHP die Beschreibung zu Cookies

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

ich glaube, du bist in der falschen Keksdose unterwegs.

Henry schrieb "HTTP-Basic-Auth" - das arbeitet mit eigenen HTTP Headern und ist von einer applicationseitigen Authentication unabhängig.

Rolf

[Ralf]

Hallo Rolf,

ich glaube, du bist in der falschen Keksdose unterwegs.

Henry schrieb "HTTP-Basic-Auth" - das arbeitet mit eigenen HTTP Headern und ist von einer applicationseitigen Authentication unabhängig.

Das macht kaum einen Unterschied für das Verständnis.

Siehe hierzu Posting Nr 4 zum Thema Commo Basic Auth

Der Browser muss wissen, dass er die Credentials an die Subdomain (oder eventuell auch die Fremddomain, je nach Browser) unaufgefordert mitsenden soll.

Ob die dann etwas damit anfangen kann, muss sie selber wissen.

LG
Ralf

[Rolf B]

Hallo Ralf,

nichtsdestotrotz sind HTTP Authentication und Authentication mit Cookies zwei sehr verschiedene Dinge mit verschiedenen Problemen.

HTTP Authentication ist ein eigenes, anwendungsunabhängiges Framework mit eigenen Headern, und eine gelungene Authentication gilt zunächst einmal für den kompletten Origin bzw. einen Realm darin.

Cookies, die eine gelungene Authentication speichern, sind dagegen abhängig vom Ressourcen-Path und werden nicht vom Server, sondern von einer Application gesetzt. Es ist eine Entscheidung der Application, für welchen Path sie den Cookie setzt.

Credentials an die Subdomain (...) unaufgefordert mitsenden

Henry verwendet keine Subdomain. Er hat eine dyndns-Adresse und darunter Pfade. Zumindest deute ich eine Beschreibung so. HTTP Authentication und Subdomains vertragen sich eh nicht. Nachdem der Browser einmal von example.org einen WWW-Authenticate Header bekommen und erfolgreich beantwortet hat, schickt er den Authorization-Header dazu bei allen Requests an example.org mit. Er tut es nicht bei www.example.org. Ob er sich auch merkt, dass bestimmte Pfade Authenticate-Requests mit verschiedenen Realms liefern und er die Credentials dazu sauber zuordnet - keine Ahnung. Dazu müsste ich rumexperimentieren.

Bei Cookies kann ich explizit Sichtbarkeiten für Domains und Pathes festlegen. Das hängt davon ab, wie der Cookie gesetzt wird. Ein Cookie, der mit Set-Cookie ... domain=selfhtml.org,path=/self gesetzt wird, wird gesendet beim Abruf von

forum.selfhtml.org/self
forum.selfhtml.org/self/2021
wiki.selfhtml.org/self

und nicht gesendet für

forum.selfhtml.org/meta
wiki.selfhtml.org/wiki
forum.se1fhtml.org/self (na? gesehen?)

Rolf

[TS]

Hello,

bitte benenne mir die Layer, auf denen sich die beiden Verfahren abspielen und benenne die wesentlichen Status der Kommunikationen.

Wo ist da genau der Unterschied?

Ich habe mich zwar nicht klar genug ausgedrückt, als ich das Beispiel von PHP und Cookies genannt habe, aber für HTTP-basic-Authentication funktioniert das analog. Die Crendentials liegen hier in den HTTP-Headern. Früher durften sie leider auch noch im Request-String übergeben werden.

Wo bei der "Cookie-Autentifizierung" die Daten liegen, ist leider auch nicht immer klar.

Wesentlich in beiden Szenarien ist hier aber, dass der Requestor wissen muss, ob er Auth-Daten an den Subrequest mitsenden soll, oder nicht. Browser, die diese Entscheidungsmöglichkeit nicht berücksichtigen, sind ein Sicherheitsleck.

Unabhängig davon sollte der requestete Server (= Application) weitere Identifizierungs- und Autentifizierungsmethoden bereit halten.

Ein Distributed Auth System erfordert mehr, als fünf Postings in einem Thread.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Tom,

wenn Du von OSI sprichst - HTTP Auth ist Teil von HTTP, also im Application Layer und damit Teil des Netzwerkprotokolls. Cookie Auth ist eine Anwendung von HTTP Cookies und liegt damit oberhalb des OSI-Stacks.

Aber wir streiten über Dinge, die mit der Frage nichts zu tun haben. Henry schreibt ganz klar HTTP Basic Auth, das schließt ein Cookie-Verfahren aus.

Beide Verfahren haben einen Zustand "abgemeldet", "Anmeldung läuft" und "angemeldet", aber bei HTTP Auth steuert das der Browser und bei einem Cookie-Verfahren steuert es die Anwendung dahinter (von Hybridverfahren abgesehen, die per HTTP Auth Seite einen Cookie als Ticket erstellen).

Ob ein Server mehr als Basic Authentication anbieten sollte, ist ebenfalls nicht die Frage. Henry hat browserspezifische Probleme mit HTTP Basic Authentication.

Der dafür genutzte Authorization Header sollte beim Übergang zu anderen Frames oder beim Öffnen von Popup-Fenstern mitkommen. Und er tut es nicht immer. Schätzt Du dieses Verhalten von Firefox als erwartungskonform ein, Tom?

Eine Idee, die ich bisher noch nicht hatte, ist HTTPS. Basic Auth macht man aus Sicherheitsgründen eigentlich nur über HTTPS. Vielleicht sind die Zertifikate, die für die Maschine1 und Maschine2 Verwendung finden, unterschiedlich. Das könnte eine Authorization invalidieren. Oder eine Maschine ist für http, die andere für https eingerichtet?

Aber bisher habe ich keine Idee, auf welchen Punkt man den Analysefinger legen sollte. Man müsste den Netzwerkverkehr im Gut- und Schlechtfall vergleichen.

Rolf

[TS]

Hello,

ich glaube, du bist in der falschen Keksdose unterwegs.

Henry schrieb "HTTP-Basic-Auth" - das arbeitet mit eigenen HTTP Headern und ist von einer applicationseitigen Authentication unabhängig.

Für das Verständnis ist das unerheblich.
Beide Methoden spielen sich im Layer Sieben und mittels HTTP/s ab.

Glück Auf
Tom vom Berg

[TS]

Hello,

Wird aber eine Webseite geöffnet, die ein eigenen Tab, oder gar ein eigenes Fenster öffnet, so wird erneut ein login am "Maschinenwebserver" benötigt. Wird wieder user/passwort eingegeben gilt die "auth" danach für alle folgenden Webseiten.

Dies war früher bei Firefox nicht so

das kann ich gerade nicht nachvollziehen, aber es ist durchaus vorstellbar, dass die Firefox-Enwickler die HTTP-AUTH-Daten seit Version X nicht mehr zwischen zwei Browser-Tabs oder gar -Fenstern hin- und herreichen.

Das hat nichts mit Browsertabs zu tun, sondern mit den Request-Zielen. Wenn die nicht übereinstimmen, oder die Cookies nicht mit "auch für Subsomains" gekennzeichnet wurden, dann darf der Browser den Cookie der Hauptdomain nicht an die Subdomains übermitteln.

Siehe hierzu z. B. die PHP-Beschereibung zu Cookies.

Und ob die Subdomain dann mit dem Cookie etwas anfangen kann, hängt davon ab, ob die Hauptdomain und die Subdomains im Hintergrund miteinander kommunizieren bzw. dasselbe Filesystem (aka Auth-System) benutzen.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Henry,

ich habe das Szenario noch nicht 100% verstanden. Da ist eine Portalseite, die über einen dyndns-Eintrag auf eine IP 1 gelenkt wird. Dort meldet man sich an - wie? Ein Forms-Login mit Cookie? Eine HTTP Basic Authentication?

Ist man angemeldet, bekommt man Links zu Maschinenservern. Einer davon wäre auf der IP 2. Dieser Link wird in einem Frame (Frame wie in frameset? Oder iframe?) geöffnet und wurde früher ohne weiteren Login angezeigt. Und das ist auch heute noch so?

Öffnet man den Link dagegen in einem neuen Tab oder Fenster, gibt's einen erneuten Login?

Meine Hypothese wäre eigentlich, dass zwischen zwei IPs weder Cookies noch HTTP Authentications geteilt werden dürften; ich frage mich, wie das überhaupt funktioniert. Ich habe es mit einem Frameset auf der IP 127.0.10.1 probiert - weder im Internet Explorer noch in Firefox oder Chrome komme ich von der einen IP ohne Login auf der IP 127.0.10.2. Die sind beide auf meinem PC, beide im IIS gehostet, mit Basic Authentication.

Rolf

[der Henry]

Hallo und vielen Dank für euer Interesse an meinem Problem.

Ich versuche es besser zu erklären.

1. Auf einem Webserver der über eine dyndns-IP erreichbar ist, stehen von allen Maschinen die index.html im jeweiligen separatem Verzeichnis ( /srv/www/htdocs/maschine_1, /srv/www/htdocs/maschine_2, /srv/www/htdocs/maschine_x )

Wenn ich nun im Browser meinedyndns/maschine_1 aufrufe wird automatisch die index.html der zugerhörigen Maschine geladen. Diese sieht wie nachfolgend aus

index.html <!DOCTYPE ... usw. <frameset rows="100%" ....> <frame name="ALL" src="http://x.x.x.x/" ....></frameset> <body ...></body></html>`

Wenn diese index.html geladen wird muss ich mich mittels HTTP-Basic-Auth anmelden. (Die Anmeldung erfolgt somit am Webserver der Maschine 1.

... somit komme ich auf den Webserver der Maschine_1 der wiederum die index.html der Maschine 1 vom Webserver der Maschine 1 lädt.

index.html auf der Maschine 1(nur die relevanten Daten) <FRAMESET ROWS="30px,94%" FRAMEBORDER=1 FRAMESPACING="0"> <FRAME Name="statusframe" SRC="status.html" Scrolling="Auto" frameborder="1"> <FRAME Name="hauptframe" SRC="maschinenname.html" Scrolling="Auto"> <noframes>Leider kann diese Seite ohne Frame-Unterst&#252;tzung nicht benutzt werden</noframes> </FRAMESET>

Jetzt wird nur noch im Webserver der Maschine 1 navigiert.

2. Wenn eine Webseite im Menü mit target="haupframe" aufgerufen wird, funktioniert alles normal, ich muss mich beim Seitenwechsel nicht nochmals anmelden. Auch ein öffnen einer Webseite in einem neuen Tab funktioniert ohne zusätzliche Anmeldung.

3. Für die Eingabe von Daten an die Maschine wird mittels win=window.open('/cgi-bin/schreibbefehle/' + prg + '.cgi','', 'width=200, height=300, screenX=150, screenY=130, location=no, hotkeys=no, directories=no, menubar=no, scrollbar=auto, toolbar=no, status=no, resizable=yes'); ein neues Brwoserfenster geöffnet, das nicht im Tab, sondern komplett separat erscheint.

• Firefox: ich muss mich einmalig beim öffnen dieses Fensters erneut anmelden, was früher nicht war.
• Chrome: keine erneute Anmeldung, alles läuft ganz normal weiter.

Ich hoffe ich konnte es noch besser erklären.

Gruß

der henry

[Rolf B]

Hallo Henry,

ich kann das mit Firefox 94 für Windows und einem IIS Webserver so nicht nachstellen.

Was ich nachstellen kann, ist eine erneute Anmeldung in Frame UND Popup, wenn der Realm der Basic Authentication nicht übereinstimmt. Das ist ein Teil der Authenticate-Anfrage des Servers. Wie ich einen Realm im IIS konfiguriere, weiß ich, wie ich das im Apache mache, weiß ich nicht.

Wie ich im Browser, in den Entwickler-Tools, die Webrequests der Authentication-Phase angezeigt bekomme, weiß ich auch nicht. FF und Chrome unterschlagen mir das; ich sehe nur den erfolgreichen HTTP 200 Request nach der Authentication. Ich musste den Wireshark anwerfen, um das zu sehen.

Ein unterschiedliches Verhalten für Frame und Popup finde ich nicht. Vielleicht kannst Du mit Wireshark oder ähnlichen Tools etwas erkennen.

Rolf

[TS]

Hello,

ich habe das Szenario noch nicht 100% verstanden. Da ist eine Portalseite, die über einen dyndns-Eintrag auf eine IP 1 gelenkt wird. Dort meldet man sich an - wie? Ein Forms-Login mit Cookie? Eine HTTP Basic Authentication?

Ist man angemeldet, bekommt man Links zu Maschinenservern. Einer davon wäre auf der IP 2. Dieser Link wird in einem Frame (Frame wie in frameset? Oder iframe?) geöffnet und wurde früher ohne weiteren Login angezeigt. Und das ist auch heute noch so?

Öffnet man den Link dagegen in einem neuen Tab oder Fenster, gibt's einen erneuten Login?

Meine Hypothese wäre eigentlich, dass zwischen zwei IPs weder Cookies noch HTTP Authentications geteilt werden dürften; ich frage mich, wie das überhaupt funktioniert. Ich habe es mit einem Frameset auf der IP 127.0.10.1 probiert - weder im Internet Explorer noch in Firefox oder Chrome komme ich von der einen IP ohne Login auf der IP 127.0.10.2. Die sind beide auf meinem PC, beide im IIS gehostet, mit Basic Authentication.

Die mir bekannten Authentifizierungssysteme sind alle Name based, haben also nicht direkt mit der IP des Hosts zu tun.

Wenn eine Unterseite, egal ob in einem iFrame oder als direkter Link also auch eine Authentifizierung benötigen, dann muss die gesondert angefordert werden.

Allerdings gibt es die Möglichkeit der Subdomain-Authentifizierung. Das bedeutet, dass das übermitteltete Cookie (Auth-Token) vom Browser auch an alle Subdomains übermittelt wird.

siehe z. B. bei PHP die Beschreibung zu Cookies

Ob die dann damit etwas anfangen können, hängt von der Backoffice-Interkommunikation ab, also, ob die Domain mit ihren Subdomains Cookies (Auth-Tokens, Sessions, ...) shared.

Generell dürfte es schon einen Bruch zwischen HTTP und HTTPS geben zwischen früher und heute. Innerhalb einer "HTTPS-Connection" darf es heute nicht mehr ohne Sonderregeln eine "HTTP-Connection" geben.

Dabei muss es dem Server egal sein, ob der Request mittels Browser oder sonstwie abgesetzt wurde.

Glück Auf
Tom vom Berg