nicht angemeldet
Hi oso_de_la_nariz,
Um es dem User zu vereinfachen (damit er nicht jedesmal sein User/PW angeben muss) möchte ich ihn einfach weiterleiten [...]
Wenn du im Internet nach Lösungen zu deinem Problem suchst, wirst du sicherlich auf die Antwort stoßen, den User auf folgende URL zu leiten:
http://username:password@example.org/
Das ist allerdings kein HTTP-Standard. Nun gut, wenn es zuverlässig funktionieren würde, könntest du es ja trotzdem benutzen - das Problem ist aber, dass es genau das nicht tut. ;-)
Früher hatten die meisten Browser dies implementiert, dass man (ohne Nachfrage an den User), auf der Zielseite dann so authentifiziert wurde. Leider wurde damit viel Unfug gebaut, diese Technik also mißbraucht - zum Beispiel:
http://www.microsoft.com:anything@boese-seite.example.org/
Ein normaler Internetuser wird hierbei denken, dass er die Seite www.microsoft.com besucht, sich von dieser Seite also Updates für sein (Windows-) Betriebssystem herunterladen etc. In Wirklichkeit besucht er aber die Seite boese-seite.example.org und ist dort lediglich als www.microsoft.com authentifiziert. Aber welcher „normale” Internetuser soll das schon wissen?
Aus diesem Grund funktioniert das heutzutage in sämtlichen verbreiteten Browsern nicht mehr, oder wenn, dann nur mit einer Sicherheitsfrage, welche der User explizit bestätigen muss.
Geht das überhaupt?
Mir sind keine Parameter bekannt die das ermöglichen. Oder mal anders gefragt: Kann ich die Eingabe der Daten (der Basic Authentification) irgendwie sinnvoll automatisieren?
Da obige Methode flach fällt, bleibt nur noch eine Lösung übrig - und zwar, du lässt deinen Server als Proxy fungieren. Im Prinzip läuft das darauf hinaus, dass du ein Script schreibst, welches die Daten vom fremden Server unter Verwendung der hinterlegten Benutzerdaten abruft und die Rückgabe des fremden Servers an den Besucher durchschleust.
So viel zur Theorie. Das praktisch umzusetzen ist allerdings ziemlich aufwändig. Es reicht nicht, einfach die Rückgabe des fremden Servers durchzureichen an den User, dein Server müsste auch alle Links (dazu gehören auch Bild-, CSS- und Javascript-Ressourcen) welche auf den fremden Server verweisen umschreiben, sodass diese Links auf deinen Server verweisen und dieser den Content ausliefern kann.
Beispiel - die fremde URL lautet http://fremder-server.invalid/startseite.html, darin ist folgender HTML-Code enthalten:
~~~html
<a href="/unterseite.html">
<img src="/img/page.jpg" alt="" /> Unterseite
</a>
Dein Server soll unter der URL http://dein-server.invalid/proxy.php?url=startseite.html die Seite zurückliefern, dann müsste dein Server das hier zurückliefern:
~~~html
<a href="/proxy.php?url=unterseite.html">
<img src="/proxy.php?url=img/page.jpg" alt="" /> Unterseite
</a>
Warum du das machen musst?
a) Weil die relativen Links der fremden Seite nicht mehr stimmen, wenn du die Seite unter einer URL auf deinem Server auslieferst.
b) Weil die Ressourcen hinter manchen URIs des fremden Servers auch geschützt sein könnten, und somit der User nach Benutzername und Passwort gefragt würde, wenn sein Browser direkt den fremden Server kontaktieren würde.
Zusammengefasst: Bei diesem Verfahren findet nur eine Kommunikation von
Client <-> Dein Server <-> Fremder Server
statt. Es findet *keine* Kommunikation von
Client <-> Fremder Server
statt.
Was würdet Ihr mir raten?
Das von mir erläuterte Verfahren, dass dein Server als Proxy fungiert, ist ziemlich aufwändig und dürfte deinen Server recht stark belasten, sodass ich davon abraten würde.
Back to the roots, jeder (vernünftige) Browser bietet eine Möglichkeit, dass ich Benutzername und Passwort speichern kann. Wenn du mir also einen ganz normalen Link auf eine fremde Seite gibst, à la
http://fremder-server.invalid/
dann klicke ich als Besucher da drauf, der Dialog für Benutzername und Passwort geht auf, ich habe die Daten eingespeichert, drücke einfach nur einmal Enter und gut ist.
Warum also alles komplizierter machen als es ist?
Viele Grüße,
~ Dennis.