Passwortübergbe mit Header ()?

[Heinzelhund]

Hallo Allesamt,

ich habe mit Hilfe von PHP und Session-Cookies einen passwortgeschützten Bereich erstellt. In diesem Bereich möchte ich nun einen Link setzten, der auf eine mittels einer .htaccess-Datei geschützten Seite verweißt.

Ich möchte dem Nutzer ein erneutes Eingeben eines Passwortes ersparen. Früher konnte man einfach einen Link im Stil von http://login:[e-mail] setzen. Da dies jedoch aus Sicherheitsgründen nicht mehr bei allen Browsern funktioniert, benötigte ich einen andere Weg.

Ist es mit PHP möglich, mittels der header()-Funktion die Zugangsdaten automatisch an den Browser zu senden, so dass dieser die Zugangsdaten auch für Folgeseiten übergibt? (Ich habe übrigens auf beide Bereiche Serverzugriff, jedoch nicht auf die Konfigurationdateien der Server.)

Ciao
Heinzelhund

[Christian Kruse]

你好 Heinzelhund,

Ist es mit PHP möglich, mittels der header()-Funktion die Zugangsdaten
automatisch an den Browser zu senden, so dass dieser die Zugangsdaten auch
für Folgeseiten übergibt?

Nein.

再见,
 CK

[Heinzelhund]

Nein.

再见,
CK

:-(
Danke.

Heinzelhund

[Tom]

Hello,

Ist es mit PHP möglich, mittels der header()-Funktion die Zugangsdaten
automatisch an den Browser zu senden, so dass dieser die Zugangsdaten auch
für Folgeseiten übergibt?

Nein.

Aber die Daten müssen doch irgendwo ankommen? Werden sie nur nicht in den User-Scope von PHP übertragen? In $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'] stehen sie doch noch drin.

diese Header kommen z.B. an, wenn man einen erfolgreichen 401-Dialog vorgenommen hat

HTTP-Header
Array
(
    [Accept] => */*
    [Accept-Encoding] => gzip, deflate
    [Accept-Language] => de
    [Authorization] => Basic dGhvbWFzOnBhdWxjaGVu
    [Connection] => Keep-Alive
    [Host] => testserver.lan.fli4l
    [Referer] => http://testserver.lan.fli4l/~thomas/test/Authentication/
    [User-Agent] => Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
)

Was hat es da mit dem Datenfeld [Authorization], speuziell der crptischen Zeichenkette auf sich? Ist das das vercryptete Passwort? Nur welcher Algorithmis liegt dem dann zugrunde?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Henryk Plötz]

Moin,

Ist es mit PHP möglich, mittels der header()-Funktion die Zugangsdaten
automatisch an den Browser zu senden, so dass dieser die Zugangsdaten auch
für Folgeseiten übergibt?

Nein.

Aber die Daten müssen doch irgendwo ankommen? Werden sie nur nicht in den User-Scope von PHP übertragen? In $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'] stehen sie doch noch drin.

HTTP-Requests werden vom Browser an den Server geschickt.
HTTP-Responses werden vom Server an den Browser geschickt.
Authorization:-Header sind Teil des Requests.
Mit header() lassen sich Response-Header setzen.

Schalten Sie auch morgen erneut ein, wenn es wieder heisst "HTTP für Anfänger".

[Authorization] => Basic dGhvbWFzOnBhdWxjaGVu

Was hat es da mit dem Datenfeld [Authorization], speuziell der crptischen Zeichenkette auf sich?

Das ist höchstgeheim und darf niemandem verraten werden, paulchen. Jeder der auch nur daran denkt die magische Zahl 2617 zu erwähnen wird instantan erscho+++ATH@QPSDIOAISD____CARRIER LOST

Ist das das vercryptete Passwort? Nur welcher Algorithmis liegt dem dann zugrunde?

Double-ROT13

[Tom]

Hello,

übertragen? In $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'] stehen sie doch noch drin.

HTTP-Requests werden vom Browser an den Server geschickt.
HTTP-Responses werden vom Server an den Browser geschickt.
Authorization:-Header sind Teil des Requests.
Mit header() lassen sich Response-Header setzen.

Schalten Sie auch morgen erneut ein, wenn es wieder heisst "HTTP für Anfänger".

Ja, danke. Ich bin immer dabei. Auch wenn die Anfänger posten ;-)

Also nochmal gaaanz langsam für die Begriffsstutzigen:

Wenn ich etwas weiterleiten will, muss ich es ja erstmal empfangen. Soweit klar?
Wenn es denn normalerweise mitgesendet wird, schaue ich mir eben an, wie dies geschieht.
Und wenn ich das begriffen habe, dann könnte ich es meinem Server ja beibringen, das genauso aufzubereiten, damit der Client die übersandten Daten dann möglichst wieder mitsendet.

Dass er das nicht so tut, wie erwartet/erhofft, haben wir ja von Christian K. schon vernommen, der zwar wieder eine sehr knappe Antwort ohne didaktischen Wert gegeben hat, an der ich aber nicht zweifle.

Es ist also durchaus angemessen gewesen, eine "Diskussion für Anfänger" hervorzurufen. Du warst so freundlich, den ersten Schritt zu machen, dann mach bitte aus dem Konituitätsgedanken heraus auch den zweiten ;-))

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Siechfred]

Tag Tom.

übertragen? In $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'] stehen sie doch noch drin.

Ja, nämlich dann, wenn sie zuvor mit einem HTTP-Request vom Client gesandt wurden. Aber das weißt du ja sicher. Ein Response kann alle möglichen Header enthalten (Liste der Response-Header), jedoch keine Authentifizierungsdaten. Wozu auch, ein Client muss sich beim Server authentifizieren, nicht umgedreht. Kein Browser dieser Welt kann etwas mit vom Server übermittelten Authentifizierungsdaten anfangen, vielmehr ist es Sache des Client dafür zu sorgen, dass an den richtigen Server die richtigen Authentifizierungsdaten übermittelt werden.

Wenn ich etwas weiterleiten will, muss ich es ja erstmal empfangen.

Hm, wie meinst du das in diesem Zusammenhang?

Wenn es denn normalerweise mitgesendet wird, schaue ich mir eben an, wie dies geschieht.

Verstehe ich dich richtig, dass du Userdaten, die mittels HTTP-AUTH übermittelt wurden, in einem Response-Header unterbringen willst? Wozu?

Und wenn ich das begriffen habe, dann könnte ich es meinem Server ja beibringen, das genauso aufzubereiten, damit der Client die übersandten Daten dann möglichst wieder mitsendet.

Warum, der Client tut dies automatisch. Irgendwie verstehe ich das Problem nicht so recht :-/

Siechfred

[Tom]

Hello,

Warum, der Client tut dies automatisch. Irgendwie verstehe ich das Problem nicht so recht :-/

Genau das ist das Problem. Du verstehst das Problem nicht.

Dabei war Henryk mit der Darstellung schon ziemlich dicht dran.

Man kann eben dem Client keine DSaten mitsenden, die er bei einem Location-Header wieder mit zurücksenden würde ....

Oder sollte es doch möglich sein?

Ein frisches Cookie wird bei einem Location-Header auch wieder zurückgesandt.
Nun wäre es also Aufgabe der Teilnehmer dieses Threads, mal herauszuarbeiten, welche Daten noch mit zurückgesandt werden. Das fände ich dann wertvoll fürs Archiv.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Siechfred]

Tag Tom.

Genau das ist das Problem. Du verstehst das Problem nicht.

Magst du es mir erklären?

Siechfred

[Tom]

Hello,

Genau das ist das Problem. Du verstehst das Problem nicht.

Magst du es mir erklären?

Ja gerne, frage einfach, wo Du nicht mehr mitgekommen bist *gbg*

Aber mal ernsthaft: Hier ist ein Klärungsbedarf vorhanden, der sich mit dem Archiv und der allgemeinen Arroganz auch nicht erledigen lässt. Man könnte durchaus mal ein paar Tipps dazu geben. Leider fallen mir die auch nicht alle aus dem Ärmel. Es gibt sicher RFCs für beide Richtungen und es gibt hier sicher einige Leute, die diese sowohl erklären als auch relativieren könnten.

Ich dachte eigentlich, dass Du dazu gehören würdest.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Siechfred]

Tag Tom.

Aber mal ernsthaft: Hier ist ein Klärungsbedarf vorhanden, der sich mit dem Archiv und der allgemeinen Arroganz auch nicht erledigen lässt. Man könnte durchaus mal ein paar Tipps dazu geben. Leider fallen mir die auch nicht alle aus dem Ärmel. Es gibt sicher RFCs für beide Richtungen und es gibt hier sicher einige Leute, die diese sowohl erklären als auch relativieren könnten.

Mag sein, aber für das konkrete Problem des OP gibt es keine Lösung. Du kannst die Authentifizierungsdaten zwar dem Client irgendwie mitteilen (z.B. mit Cookies), aber du kannst eben nicht beeinflussen, was der Client damit macht, insbesondere kannst du keinen (hier zwingend erforderlichen) Request generieren. Von mir aus nenne es einen Nachteil von HTTP-AUTH, es ist aber nunmal - abgesehen von proprietären (MS-)Techniken - nicht möglich.

Siechfred

[Tom]

Hello,

Mag sein, aber für das konkrete Problem des OP gibt es keine Lösung. Du kannst die Authentifizierungsdaten zwar dem Client irgendwie mitteilen (z.B. mit Cookies), aber du kannst eben nicht beeinflussen, was der Client damit macht, insbesondere kannst du keinen (hier zwingend erforderlichen) Request generieren. Von mir aus nenne es einen Nachteil von HTTP-AUTH, es ist aber nunmal - abgesehen von proprietären (MS-)Techniken - nicht möglich.

Das hatte ich oben auch schon eingeräumt.
Nichtsdestotrotz (was für ein Wort) würde ich das als diskussionswürdig empfinden, ob es denn bei HTTP sinnvoll wäre, dies zu ermöglichen, oder ob es eher eine Sicherheitslücke bedeuten würde.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[dedlfix]

Nichtsdestotrotz (was für ein Wort)

Übrigens: "Nichtsdestotrotz, aus der Nase fließt kein Honig" pflegt man so schön zu sagen.

würde ich das als diskussionswürdig empfinden, ob es denn bei HTTP sinnvoll wäre, dies zu ermöglichen, oder ob es eher eine Sicherheitslücke bedeuten würde.

Das hatte sich Netscape auch schon gefragt und daraufhin die Kekse erfunden. Alle anderen scheinen das auch gut gefunden zu haben und haben das implementiert. (Vor- und Nachteile sind hinreichend erörtert und bekannt.) So wie es aussieht erachtet es keiner für nötig das Rad noch einmal neu zu erfinden. Prinzipbedingt (Hier der eigenständige Server, da der eigenständige Client, dazwischen das statuslose Protokoll http) wird es da auch nicht besseres geben können.

[dedlfix]

Nun wäre es also Aufgabe der Teilnehmer dieses Threads, mal herauszuarbeiten, welche Daten noch mit zurückgesandt werden. Das fände ich dann wertvoll fürs Archiv.

Das hab ich auch schon gesucht und nichts gefunden. Außer Keksen gibts da nichts. In meinem Fall brauchte ich eine Session-ID und der Auftraggeber wollte aus halbwissenbegründeten Sicherheitsbedenken keinen Süßkram. Wir konnten ihn dann doch von zuckerfreien (sprich ohne expire-Parameter => verfällt beim Browserschließen) Cookies überzeugen.

[Axel Richter]

Hallo,

Und wenn ich das begriffen habe, dann könnte ich es meinem Server ja beibringen, das genauso aufzubereiten, damit der Client die übersandten Daten dann möglichst wieder mitsendet.

Dass er das nicht so tut, wie erwartet/erhofft, haben wir ja von Christian K. schon vernommen,

Wenn es Dir um Daten der Basic HTTP Authentication geht, dann kommt es drauf an, was Du erwartest. Normalerweise sendet der Client die Anmeldedaten (Nutzer und Passwort) innerhalb einer Browser-Sitzung immer wieder automatisch mit, wenn vom _selben_ Server ein 401 mit einem realm kommt, den der Browser gecached hat. Hierduch muss man sich in einer Sitzung am selben Server nicht mehrfach anmelden, solange sich der realm (der geschütze Bereich) nicht ändert.

http://www.faqs.org/rfcs/rfc2617.html
...

The authentication parameter realm is defined for all authentication
   schemes:

realm       = "realm" "=" realm-value
      realm-value = quoted-string

The realm directive (case-insensitive) is required for all
   authentication schemes that issue a challenge. The realm value
   (case-sensitive), in combination with the canonical root URL (the
   absoluteURI for the server whose abs_path is empty; see section 5.1.2
   of [2]) of the server being accessed, defines the protection space.
   These realms allow the protected resources on a server to be
   partitioned into a set of protection spaces, each with its own
   authentication scheme and/or authorization database. The realm value
   is a string, generally assigned by the origin server, which may have
   additional semantics specific to the authentication scheme. Note that
   there may be multiple challenges with the same auth-scheme but
   different realms.

A user agent that wishes to authenticate itself with an origin
   server--usually, but not necessarily, after receiving a 401
   (Unauthorized)--MAY do so by including an Authorization header field
   with the request. A client that wishes to authenticate itself with a
   proxy--usually, but not necessarily, after receiving a 407 (Proxy
   Authentication Required)--MAY do so by including a Proxy-
   Authorization header field with the request.  Both the Authorization
   field value and the Proxy-Authorization field value consist of
   credentials containing the authentication information of the client
   for the realm of the resource being requested. The user agent MUST
   choose to use one of the challenges with the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge.
...
   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.
   Similarly, when a client sends a request to a proxy, it may reuse a
   userid and password in the Proxy-Authorization header field without
   receiving another challenge from the proxy server. See section 4 for
   security considerations associated with Basic authentication.
...

viele Grüße

Axel