nicht angemeldet
Gleiche Session für 2 URLs möglich?
Guten Tag,
ich möchte eine PHP-Session auf einer Webseite für verschiedenes nutzen - unter anderem für einen Passwort-geschützten Bereich.
Nun soll sich allerdings sobald man auf einen Bestimmten Navigationspunkt klickt, das Aussehen und auch die URL der Seite ändern. Der Server etc. bleibt gleich, Seitenaufbau und Loginstatus sollen erhalten bleiben. Kriege ich das irgendwie hin? Bisher bin ich unter der alternativen URL einfach nicht eingeloggt.
Ich habe beim stöbern gelesen, dass ist ggf. per htaccess die Gültigkeit der Cookies anpassen/erweitern muss, allerdings bin ich dafür nicht fit genug.
Kann mir jemand helfen?
Vielen Dank schon mal!
Gruß, Henning
-
Tach!
[PHP-Session] ... [die URL der Seite ändert sich]. Der Server etc. bleibt gleich, Seitenaufbau und Loginstatus sollen erhalten bleiben. Kriege ich das irgendwie hin? Bisher bin ich unter der alternativen URL einfach nicht eingeloggt.
Die Session an sich ist nicht an die URL gebunden. Die ID kann auch URL- und serverübergreifend weitergegeben werden. Allerdings sind Cookies per Default auf Domänen beschränkt. Lediglich für Subdomänen können sie freigegeben werden.
Cookies als Session-ID-Transportmedium eignen sich also nur bei Subdomänen.
Ich habe beim stöbern gelesen, dass ist ggf. per htaccess die Gültigkeit der Cookies anpassen/erweitern muss, allerdings bin ich dafür nicht fit genug.
Für Session-Cookies bietet PHP selbst Funktionen an, um diese zu konfigurieren. Siehe Handbuchkapitel zu den Sessions.
dedlfix.
-
Tach!
[PHP-Session] ... [die URL der Seite ändert sich]. Der Server etc. bleibt gleich, Seitenaufbau und Loginstatus sollen erhalten bleiben. Kriege ich das irgendwie hin? Bisher bin ich unter der alternativen URL einfach nicht eingeloggt.
Die Session an sich ist nicht an die URL gebunden. Die ID kann auch URL- und serverübergreifend weitergegeben werden. Allerdings sind Cookies per Default auf Domänen beschränkt. Lediglich für Subdomänen können sie freigegeben werden.
Cookies als Session-ID-Transportmedium eignen sich also nur bei Subdomänen.
Ich habe beim stöbern gelesen, dass ist ggf. per htaccess die Gültigkeit der Cookies anpassen/erweitern muss, allerdings bin ich dafür nicht fit genug.
Für Session-Cookies bietet PHP selbst Funktionen an, um diese zu konfigurieren. Siehe Handbuchkapitel zu den Sessions.
dedlfix.
Hallo und danke schonmal.
Ich denke, Du meintest das hier: http://de2.php.net/manual/de/function.session-set-cookie-params.php
Dadurch kann ich in der Tat "nur" subdomains freigeben, was etwas ärgerlich ist. Eigentlich sollten es wirklich 2 Domänen sein, also www.test1.de und wechsel auf www.test2.de. Habe ich da überhaupt keine Möglichkeit bzw. müsste ich ein anderes Verfahren anwenden?
Gruß!
-
Hallo,
Dadurch kann ich in der Tat "nur" subdomains freigeben, was etwas ärgerlich ist. Eigentlich sollten es wirklich 2 Domänen sein, also www.test1.de und wechsel auf www.test2.de. Habe ich da überhaupt keine Möglichkeit bzw. müsste ich ein anderes Verfahren anwenden?
Unter www.test1.de die Sessiondaten serialisiert in einer DB speichern, SESSION_ID als Parameter an www.test2.de übergeben und hier die Sessiondaten aus der DB in die Session einlesen.
vg paranoia
-
Tach!
Bitte zitiere nur das, worauf du dich konkret beziehst und nicht einfach alles. Danke.
Ich denke, Du meintest das hier: http://de2.php.net/manual/de/function.session-set-cookie-params.php
Dadurch kann ich in der Tat "nur" subdomains freigeben, was etwas ärgerlich ist. Eigentlich sollten es wirklich 2 Domänen sein, also www.test1.de und wechsel auf www.test2.de. Habe ich da überhaupt keine Möglichkeit bzw. müsste ich ein anderes Verfahren anwenden?Du brauchst nur für die Session-ID ein anderes Transportmedium. Cookies scheiden aus. Wo kann man denn bei HTTP sonst noch Daten übertragen? URL und POST.
An die Session-Daten selbst brauchst du ja im Gegesatz zu paranoias Vorschlag keine Hand anzulegen, die werden vom Session-Mechanismu ja schon gut aufgehoben.
dedlfix.
-
Hallo,
An die Session-Daten selbst brauchst du ja im Gegesatz zu paranoias Vorschlag keine Hand anzulegen, die werden vom Session-Mechanismu ja schon gut aufgehoben.
Stimmt, ist ja derselbe Server...
vg paranoia
-
Du brauchst nur für die Session-ID ein anderes Transportmedium. Cookies scheiden aus. Wo kann man denn bei HTTP sonst noch Daten übertragen? URL und POST.
Eigentlich stand ich grade wie der Ochs vorm Berg und wollte schon über den Smartypants-Ton moppern ;) Aber dann habe ich einmal Augen gerieben, ausprobiert und siehe da, klappt doch! Vielen Dank für die schnelle Auskunft und den guten Tip. Ich übergebe nun beim wechsel der Domäne die Session-ID mit, und setze sie in dem Fall neu:
if (isset($_GET["setid"])) { session_id($_GET["setid"]); }
Werde ich noch auf ein Formular mit Post umschreiben, soll ja nicht jeder sehen, aber es geht schonmal.
Hochachtungsvoll,
Schönen Abend!-
Leider muss ich nochmal zurückziehen ... vielleicht habe ich auch etwas nicht ganz verstanden oder falsch angewand?
Folgenden Code habe ich eingebaut - die Variable $setid beinhaltet den Namen der Session:
if (isset($_GET["setid"])) { session_id($_GET["setid"]); }Das funktioniert erstmal nur genau einmal - beim direkten Wechsel der Domänen ... dann nämlich, wenn der Code oben ausgeführt wird. Beim nächsten Klick wird wieder die "eigene" Session verwendet, die der neuen Domäne.
Liegt das daran *duck*, dass aus Sicherheitsgründen die Übergabe der Session über die URL nicht gestattet ist? Ohne Cookies läuft bei dem Projekt nichts, kann das dann überhaupt funktionieren?
Gruß, H.
-
Tach!
if (isset($_GET["setid"])) { session_id($_GET["setid"]); }
Das funktioniert erstmal nur genau einmal - beim direkten Wechsel der Domänen ... dann nämlich, wenn der Code oben ausgeführt wird. Beim nächsten Klick wird wieder die "eigene" Session verwendet, die der neuen Domäne.Wann kommt das session_start()? Hoffentlich erst danach.
Liegt das daran *duck*, dass aus Sicherheitsgründen die Übergabe der Session über die URL nicht gestattet ist?
Das interessiert den Session-Mechanismus nicht die Bohne, zumal "setid" sicher ungleich session.name (Default: PHPSESSID) ist.
Ohne Cookies läuft bei dem Projekt nichts, kann das dann überhaupt funktionieren?
Sprich: session.use_only_cookies steht auf 1 oder on? Für den Fall ja.
dedlfix.
-
Wann kommt das session_start()? Hoffentlich erst danach.
*hust*
Danke.
:-)
-
-
-
-
-
-
-
Hello Henning,
die erste Frage sollte lauten "wie funktioniert der Sessionmechanismus?"
Nehmen wir mal an, Du verwendest den PHP-Standardmechanismus ausschließlich mit Cookies. Dann wird Dir beim Start einer Session vom Server passend zur Domain ein Cookie gesendet und der Browser speichert diesen ab, sofern er passend eingestellt ist. Beim nächsten Zugriff auf dieselbe Domain sendet er dem Server den Cookie mit und dieser kann daran erkennen, welcher User gerade den Request gesendet hat.
Wenn jetzt ein anderer User (anderer Client, anderer Browser) auf derselben Domain gelichzeitig surft, erhält dieser sinnvollerweise einen anderen eigenen Cookie.
Der Schlüsselvorrat der Cookies ist so groß gewählt, dass zufällige Übereinstimmungen zwischen zwei Clients nahezu ausgeschlossen sind und auch das Erraten eines Cookies äußerst schwer fällt. Hier kommt dann auch noch die Zeit ins Spiel. Ein Session-Cookie sollte nach einer möglichst kurzen Zeit ablaufen, also ungültig werden. Dies kann man bei PHP zusätzlich noch mit der Funktion
http://de2.php.net/manual/en/function.session-regenerate-id.php
unterstützen.Da bei HTTP alles unverschlüsselt über das Netz übertragen wird, liegt hier also der Schwachpunkt. Besser ist daher die Übertragung von Zugriffs-Schlüsseln (und Daten) per HTTPS.
Das Übertragen von Cookies auf andere Seiten (Domains) wird vom Browser üblicherweise nicht unterstützt. Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen. Am einfachsten geht das, wenn dies in beiden Dokumenten bereits vorbereitet ist. Dann kannst Du den eigenen Cookie auslesen und als Parameterwert in den Link/ das Action-Attribut der zweiten Seite einbauen.
<?php ### Beispiel zur Cookieweitergabe an andere Seiten ###
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>Cookie</TITLE>
</HEAD><BODY onload="alert(document.cookie); document.getElementById('c1').value=document.cookie;">
<form action="">
<input id="c1" type="text" name="cookie1">
<input type="submit" name="btn[send]" value="senden"></form>
</BODY>
</HTML>Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello Henning,
noch eine bisschen mehr dazu, damit Du nicht vor der Wand stehst :-)
Die Übertragung an die zweite Seite, die hier im Action-Attribut festgelegt werden muss, findet hier per Post-Parameter statt. Den musst Du dann nur weiterverarbeiten auf der Empfängerseite und feststellen, ob es eine passende Session dafür gibt. Die Übertragung kann selbstverständlich ach in einem hidden Input-Element stattfinden und auch von JavaScript schon besser vorbereitet werden, insbesondere, wenn es mehrere Cookies für die Seite gibt, die dann vielleicht die andere Seite gar nicht alle etwas angehen.
<?php
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>Cookie</TITLE>
</HEAD><BODY onload="alert(document.cookie); document.getElementById('c1').value=document.cookie;">
<form action="" method="post">
<?php if(isset($_POST['cookie1'])) {echo '<p>'.$_POST['cookie1']."</p>\r\n";} ?>
<input id="c1" type="text" name="cookie1" size="50">
<input type="submit" name="btn[send]" value="senden"></form>
</BODY>
</HTML>Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Da bei HTTP alles unverschlüsselt über das Netz übertragen wird, liegt hier also der Schwachpunkt. Besser ist daher die Übertragung von Zugriffs-Schlüsseln (und Daten) per HTTPS.
Dann muss die ganze Sioetzung aber schon von vorn herein auf HTTPS laufen, denn einen Wechsel von und zu HTTPS ist wie ein Domainen-Wechsel und den überleben Cookies nicht.
Das Übertragen von Cookies auf andere Seiten (Domains) wird vom Browser üblicherweise nicht unterstützt.
Formulierungsfehler. Der Browser sendet Cookies nur innerhalb einer Domain (plus HTTP/HTTPS-Unterscheidung) wieder zum Server zurück. "Andere Seiten" interessieren dabei nicht, weil die Domain hier das dominante Glied ist.
Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen.
Aber nicht (so ohne weiteres) domainübergreifend. Sonst lass ich mal deine Bankseite in einem Frame laufen und schaue, was du da so für Cookies verwendest.
dedlfix.
-
Hello,
Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen.
Aber nicht (so ohne weiteres) domainübergreifend. Sonst lass ich mal deine Bankseite in einem Frame laufen und schaue, was du da so für Cookies verwendest.
Siehe Beispiel...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen.
Aber nicht (so ohne weiteres) domainübergreifend. Sonst lass ich mal deine Bankseite in einem Frame laufen und schaue, was du da so für Cookies verwendest.
Siehe Beispiel...Wo ist da der domainübergeifende Aspekt? Ich sehe nur ein Versenden des Cookies per Formular an dieselbe Seite. Wenn du das action-Attribut mit einer URL der anderen Domain noch ausgefüllt sehen willst, ... dazu brauchst du kein Javascript, den Link (oder das Hidden-Input-Element) kannst du auch auf dem Server generieren. Der kennt ja die aktuelle Session-ID schließlich.
dedlfix.
-
-
Moin!
Tach!
Da bei HTTP alles unverschlüsselt über das Netz übertragen wird, liegt hier also der Schwachpunkt. Besser ist daher die Übertragung von Zugriffs-Schlüsseln (und Daten) per HTTPS.
Dann muss die ganze Sioetzung aber schon von vorn herein auf HTTPS laufen, denn einen Wechsel von und zu HTTPS ist wie ein Domainen-Wechsel und den überleben Cookies nicht.
Das ist falsch. Bei Cookies gilt nicht die Same-Origin-Policy, sondern ein deutlich weniger strenger Mechanismus. Ein Cookie für eine Domain gilt, sofern nicht explizit "secure" gemacht, immer für HTTP und HTTPS gleichermaßen.
Ebenso kann man definieren, dass das Cookie nur bei HTTP-Kommunikation verwendet wird (httponly), aber nicht für Javascript lesbar ist. (Es soll aber wohl Angriffsmöglichkeiten geben, die das aushebeln.)
Das Übertragen von Cookies auf andere Seiten (Domains) wird vom Browser üblicherweise nicht unterstützt.
Formulierungsfehler. Der Browser sendet Cookies nur innerhalb einer Domain (plus HTTP/HTTPS-Unterscheidung) wieder zum Server zurück. "Andere Seiten" interessieren dabei nicht, weil die Domain hier das dominante Glied ist.
Domain (ggf. Wildcard-Angabe für alle Third-Level-Domains einer Second-Level-Domain) und Pfad sind die Kriterien, das Protokoll nur ausnahmsweise (siehe oben).
Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen.
Aber nicht (so ohne weiteres) domainübergreifend. Sonst lass ich mal deine Bankseite in einem Frame laufen und schaue, was du da so für Cookies verwendest.
Das Javascript, geladen von der Cookiedomain, angewandt auf eine Seite der Cookiedomain, kann problemlos ein Cookie ohne "httponly" auslesen und als Parameter an ein Bild hängen, welches von einer ganz anderen Domain geladen wird. Außerdem könnte Javascript versuchen, direkt ein Cookie mit dem Gültigkeitsbereich einer Drittdomain zu setzen, auch wenn das von Browsern gern mal vereitelt wird.
- Sven Rautenberg
-
-