nicht angemeldet
Sessions - Anfängerfragen / Verständnisüberprüfung
Hi,
ich habe mich heute erstmalig mit Sessions in PHP (Verwendete Version ist 5-53STABLE-STANDARD) beschäftigt. Ich möchte in diesem Post gerne abklären, ob ich da die Basics wirklich richtig verstanden habe - also kurz zusammenfassen, womit ich mich bisher beschäftigt habe und wie ich das bisher gelesene interpretiere. Ich hoffe, es findet sich jemand, der mich darauf aufmerksm macht, wenn ich etwas mißinterpretiere oder falsch verstehe. Im Anschluß habe ich dann auch noch Fragen zu diesem Thema.
Der Parameter 'session.auto_start' in meiner php.ini hat den Wert '0'. Hätte er den Wert '1', dann würde bei jedem Aufruf einer php-Ressource eine Session gestartet werden bzw. eine bestehende Session würde fortgesetzt werden. Da der Wert aber '0' ist, muß ich, wenn ich eine Session möchte, diese manuell starten und schreibe deshalb gleich zu Beginn als allererstes, also gleich nach dem einleitenden '<?php' ein 'session_start();' in die nächste Zeile. Habe ich das soweit richtig verstanden?
Durch mein 'session_start();' wird also eine Session gestartet bzw. eine schon bestehende wieder aufgenommen. Session bedeutet, dass es ab diesem Zeitpunkt ein Array mit dem Namen '$_SESSION' gibt, in welches ich jetzt beliebig viele Variablen/Werte schreiben kann und andere Seiten, die dann mit dieser Session weiterarbeiten, auf diese Werte bzw. dieses Array zugreifen können. In dem Moment, wo eine Session gestartet wird, vergibt der Server auch ein Erkennungsmerkmal für diese Session, damit sie identifiziert werden kann. Dieses Erkennungsmerkmal ist die SID. Standartmäßig hat die SID den Namen 'PHPSESSID' und einen (durch Zufallsgenerator entstandenen?) eindeutigen Wert, der vom Server, auf dem PHP läuft, vergeben wird. Der Namen der SID wird ebenfalls durch die php.ini geregelt, nämlich durch den Parameter 'session.name'. Habe ich das soweit richtig verstanden?
In meiner php.ini haben die Parameter 'session.use_cookies' und 'session.use_only_cookies' beide den Wert '1'. Das bedeutet, dass der Wert meiner SID automatisch durch ein Cookie beim Client hinterlegt wird. Ruft nun der Client eine weitere php-Ressource ab, dann sendet er in der Anfrage dafür im Header automatisch den Wert der SID mit. Bildlich gesprochen: Er sagt dem Client: Nun parse mir bitte die Ressource 'foo.php' ... and by the way ... ich bin der Kunde mit der SID 'bar'. Somit erkennt mich der Server und schickt mir die Ressource 'foo.php' inclusive aller Werte/Variablen des dieser Session dazugehörenden Arrays '$_SESSION'. Habe ich das soweit richtig verstanden?
Da es sein kann, dass User in ihrem Browser Cookies deaktiviert haben, muß ich mich jetzt aber darum kümmern, dass sich auch diese User beim Aufruf der nächsten Ressource für eine Session identifizieren können - sprich, dass auch diese User die SID auf den Weg mitbekommen. Wenn ich also einen Link von der Session-startenden Seite zu einer nächsten schreibe, dann mache ich das so: <a href="nextpage.php?<?php echo htmlspecialchars(SID); ?>">weiter</a> Dabei passiert Folgendes: Wenn der User Cookies akzeptiert, wird die Seite als 'nextpage.php?' aufgerufen und die SID im Header, also nicht sichtbar, mitgesendet. Wenn der Browser des Users Cookies nicht akzeptiert, wird die Seite als 'nextpage.php?PHPSESSID=7e7467a2d2...' aufgerufen. Die SID ist somit sichtbar. Das 'htmlspecialchars()' ist eine Sicherheits-Absicherung gegen bösartige Angriffe. Der Grund, warum die URL im ersten Fall nicht mit der SID verlängert wird, ist der Wert '1' des Parameters ''session.use_only_cookies' in der php.ini. Habe ich das soweit richtig verstanden?
OK, hier nun meine Fragen. Ich freue mich über jede beantwortete.
1.) Habe ich das Session-Sytsem, zumindest mal den Anfang davon, grundlegend richtig verstanden? Gibt es irgendwelche weiteren Session-Parameter in der php.ini, auf die ich aus bestimmten Gründen achten muß?
2.) Was würde denn passieren, wenn in meiner php.ini der Parameter 'session.use_only_cookies' den Wert '0' hätte? Dann würde also die SID nicht nur über den Cookie und weiter dann im Header der nächsten Anfrage zum Client kommen, sondern auch ... wie??? Und wenn jetzt zusätzlich auch noch der Parameter 'session.use_cookies' den Wert '0' hätte, dann gäbe es also keinen gesetzten Cookie und das weitere Prozedere wäre ... was???
3.) Gegen welche Art von Angriff bzw. Mißbrauch schütze ich mich eigentlich durch die verwendung des 'htmlspecialchars()' beim Anhängen der SID an eine URL?
4.) Bleiben wir bei meiner Konfiguration. Es wird nur mit Cookies gearbeitet - und nehmen wir weiters an, der Browser des Users läßt Cookies zu. Das bedeutet, um bei obigem Beispiel zu bleiben, dass die nächste Seite als 'nextpage.php?' aufgerufen wird. Mich nervt dieses nun sinnlose Fragezeichen am Ende der URL sehr. Muß ich damit leben oder kann ich den Code irgendwie so abändern, dass nur 'nextpage.php' aufgerufen wird, wenn Cookies akzeptiert werden und die SID somit im Header mitgesendet wird?
5.) Nicht verstanden habe ich das Beenden einer Session. Wenn ich noch vor dem 'session_start()' ein 'session_set_cookie_params('3600');' setze - was bedeutet das genau? Dass nach 1 Stunde alles weg ist, also die Variablen/Werte im Arry plus Name und wert der ID, so als ob es also nie eine Session gegeben hätte, oder ist das nur die Gültigkeitsdauer des Arrayinhalts? Die entsprechende Seite im Manual macht mich nicht ganz schlau. Genauso die Funktion session_destroy. Da steht im Manual:
session_destroy() löscht alle in Verbindung mit der aktuellen Session stehenden Daten. Mit der Session zusammenhängende globale Variablen und das Session-Cookie werden nicht gelöscht. Um wieder Session-Variablen verwenden zu können, muss session_start() aufgerufen werden. Um die Session komplett zu löschen, z.B. um einen Benutzer auszuloggen, muss auch die Session-ID gelöscht werden. Wenn zum Verfolgen der Session ein Cookie benutzt wird (standardmäßige Einstellung), muss das Session-Cookie gelöscht werden. Dafür kann setcookie() verwendet werden.
Das bringt mich nicht wirklich weiter. Was also sollte ich an der Stelle im Code, an dem alles (Session, Session Name, Session ID, Inhalt des Session-Arrays) gelöscht werden soll, schreiben? Und was genau bedeutet der Parameter 'session.cache_expire' in der php.ini, der bei mir standardmäßg den Wert '180' hat? Das hat doch auch was mit der Dauer der Gültigkeit zu tun, oder? Also die Beendigung und Dauer einer Session ... das habe ich noch nicht ganz verstanden.
6.) Bei oben beschriebenen Einstellungen - bin ich auf der sicheren Seite oder ist Arbeiten mit Sessions sehr gefährlich? Worauf muß ich noch achten? Gibt es Aspekte, die ich bis jetzt noch gar nicht erwähnt habe? Themen oder Internetseiten, mit denen ich mich noch beschäftigen soll?
Ich bedanke mich schon jetztbei allen Teilnehmern für ein interessantes Brainstorming zum Thema 'Sessions'. :-)
MfG
Hugo E.B.
-
Meine unvollständigen Anmerkungen:
Somit erkennt mich der Server und schickt mir die Ressource 'foo.php' inclusive aller Werte/Variablen des dieser Session dazugehörenden Arrays '$_SESSION'. Habe ich das soweit richtig verstanden?
Nein, die Werte aus $_SESSION werden nicht automatisch mitgesendet.
Das '
htmlspecialchars()' ist eine Sicherheits-Absicherung gegen bösartige Angriffe.Nein, es wandelt nur Zeichen um die im HTML-Kontext kein HTML sein sollen, siehe auch htmlentities().
3.) Gegen welche Art von Angriff bzw. Mißbrauch schütze ich mich eigentlich durch die verwendung des '
htmlspecialchars()' beim Anhängen der SID an eine URL?Gegen keine Art.
4.) Bleiben wir bei meiner Konfiguration. Es wird nur mit Cookies gearbeitet - und nehmen wir weiters an, der Browser des Users läßt Cookies zu. Das bedeutet, um bei obigem Beispiel zu bleiben, dass die nächste Seite als 'nextpage.php?' aufgerufen wird. Mich nervt dieses nun sinnlose Fragezeichen am Ende der URL sehr. Muß ich damit leben oder kann ich den Code irgendwie so abändern, dass nur 'nextpage.php' aufgerufen wird, wenn Cookies akzeptiert werden und die SID somit im Header mitgesendet wird?
Natürlich, finde raus ob Cookies akzeptiert werden und füge an die url nur dann was an, wenn dem nicht so ist.
5.) Nicht verstanden habe ich das Beenden einer Session. Wenn ich noch vor dem '
session_start()' ein 'session_set_cookie_params('3600');' setze - was bedeutet das genau? Dass nach 1 Stunde alles weg ist, ...Das ist ein Cookie-Parameter, der hat mit der Session auf dem Server unmittelbar nichts zu tun, er bestimmt nur die _gewünschte_ Lebensdauer des Cookie.
Und was genau bedeutet der Parameter 'session.cache_expire' in der php.ini, der bei mir standardmäßg den Wert '180' hat? Das hat doch auch was mit der Dauer der Gültigkeit zu tun, oder? Also die Beendigung und Dauer einer Session ... das habe ich noch nicht ganz verstanden.
Der ist für die Lebensdauer der Session (auf dem Server) zuständig.
6.) ... bin ich auf der sicheren Seite oder ist Arbeiten mit Sessions sehr gefährlich?
Das hängt grundsätzlich maßgeblich davon ab, was für Daten du in der Session verwendest und was Du anhand der Session tust. Einstellungen für die benutzerspezifische Darstellung der Seite sind weniger kritisch als der Zugang zum Adminbereich. Solange ich so eine Frage wie Du sie stellst stellen müßte, benutze ich Sessions nur in einer Weise, daß nichts was damit passieren kann schädlich sein kann.
-
Hi!
Nein, es wandelt nur Zeichen um die im HTML-Kontext kein HTML sein sollen, siehe auch htmlentities().
Nö, htmlentities() behandelt zwar auch die HTML-eigenen Zeichen, es dient aber vor allem zur NCR-Erzeugung, gehört also eher zum Thema Zeichenkodierung. Für die HTML-Kontext-Behandlung ist htmlspecialchars() ausreichend.
3.) Gegen welche Art von Angriff bzw. Mißbrauch schütze ich mich eigentlich durch die verwendung des '
htmlspecialchars()' beim Anhängen der SID an eine URL?
Gegen keine Art.Und was ist mit HTML- und Javascript-Injection, oder allgemein gesagt, alles was im Browser ausgeführt werden kann? Der Angriffsschutz ist in meinen Augen jedoch eher eine Nebenwirkung. Man braucht die Behandlung, um syntaktisch korrekte Daten zu erzeugen. Diese sind dann aufgrund ihrer Korrektheit sicher.
Und was genau bedeutet der Parameter 'session.cache_expire' in der php.ini, der bei mir standardmäßg den Wert '180' hat? Das hat doch auch was mit der Dauer der Gültigkeit zu tun, oder? Also die Beendigung und Dauer einer Session ... das habe ich noch nicht ganz verstanden.
Der ist für die Lebensdauer der Session (auf dem Server) zuständig.
Das widerspricht meinem Rechercheergebnis. Ich fand dazu bei session_cache_limiter(), dass es sich um HTTP-Header handelt, also nur die Lebensdauer in Web- und Browser-Caches vorschlägt.
Lo!
-
Hello,
Nö, htmlentities() behandelt zwar auch die HTML-eigenen Zeichen, es dient aber vor allem zur NCR-Erzeugung, gehört also eher zum Thema Zeichenkodierung. Für die HTML-Kontext-Behandlung ist htmlspecialchars() ausreichend.
Und im Falle des OP wäre noch raw_url_encode() notwendig, wenn er es denn selber machen will...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Für die HTML-Kontext-Behandlung ist htmlspecialchars() ausreichend.
Und im Falle des OP wäre noch raw_url_encode() notwendig, wenn er es denn selber machen will...Ja, stimmt. Erst URL-kodieren, weil der Wert in eine URL einfließen soll, und diese dann nach htmlspecialchars() in HTML einfügen.
Lo!
-
-
Und was ist mit HTML- und Javascript-Injection, oder allgemein gesagt, alles was im Browser ausgeführt werden kann?
Was soll damit sein?
-
Hi!
Und was ist mit HTML- und Javascript-Injection, oder allgemein gesagt, alles was im Browser ausgeführt werden kann?
Was soll damit sein?Die Session-ID ist ein vom Anwender änderbarer Wert. Wenn man den einfach so ins HTML stellt, dann landet das, was da jemand als ID angegeben hat, im HTML. Oder ist das deiner Meinung/deines Wissen nach anders?
Lo!
-
Und was ist mit HTML- und Javascript-Injection, oder allgemein gesagt, alles was im Browser ausgeführt werden kann?
Was soll damit sein?Die Session-ID ist ein vom Anwender änderbarer Wert.
Die die vom Nutzer übermittelt wird auf jeden Fall. Warum sollte man aber eine unbekannte Session-ID benutzen um damit eine neue Session anzulegen? Wer macht so was und warum macht php so was, wenn man es läßt? Kurze Rede noch kürzerer Sinn, Du hast Recht (ich weiß schon warum ich etwas lieber von Grund auf selber mache).
Wenn man den einfach so ins HTML stellt, dann landet das, was da jemand als ID angegeben hat, im HTML. Oder ist das deiner Meinung/deines Wissen nach anders?
Bei Eingaben auf jeden Fall, auch könnte schädlicher Code in einer zufällig erzeugten Session-ID stehen (nehme ich an). Die Ausgabe muß also in jedem Fall behandelt werden.
Ich hatte auf diesem Weg (ich meine über die dann tatsächlich verwendete ID) einen geziehlten Angriff nur nicht als möglich erwartet und die Frage war ja nach session-spezifischen gezielten Angriffen und nicht nach allgemeinen Sicherheitsaspekten.
-
-
-
-
-
Hi!
[...] muß ich, wenn ich eine Session möchte, diese manuell starten und schreibe deshalb gleich zu Beginn als allererstes, also gleich nach dem einleitenden '<?php' ein 'session_start();' in die nächste Zeile. Habe ich das soweit richtig verstanden?
Jein. Es darf lediglich vor dem session_start() keine andere Ausgabe außer HTTP-Headern (Funktion header()) erfolgt sein. Wenn du zum Beispiel nach dem EVA-Prinzip strukturierst, hast du ja erst ganz zum Schluss irgendwelche Nutzdatenausgaben, und bis dahin kannst du beliebig Header generieren, auch den Cookie-Header von session_start().
[$_SESSION und SID] Habe ich das soweit richtig verstanden?
Ja. Das wichtigste ist $_SESSION. Die SID ist nett zu wissen, ist aber nicht unbedingt kriegsentscheidend. Das PHPSESSID wirst du als Keksname oder bei angehängtem URL-Parameter wiederfinden.
In meiner php.ini haben die Parameter 'session.use_cookies' und 'session.use_only_cookies' beide den Wert '1'. Das bedeutet, dass der Wert meiner SID automatisch durch ein Cookie beim Client hinterlegt wird.
Und nur durch einen Cookie, keinen angehängten URL-Parameter.
Ruft nun der Client eine weitere php-Ressource ab, dann sendet er in der Anfrage dafür im Header automatisch den Wert der SID mit. Bildlich gesprochen: Er sagt dem Client: Nun parse mir bitte die Ressource 'foo.php' ... and by the way ... ich bin der Kunde mit der SID 'bar'. Somit erkennt mich der Server und schickt mir die Ressource 'foo.php' inclusive aller Werte/Variablen des dieser Session dazugehörenden Arrays '$_SESSION'. Habe ich das soweit richtig verstanden?
Jein. Aus Sicht des Browsers existiert nur ein Cookie für die Domain (und Path, wenn du den Default-Wert '/' änderst), das er mitsendet. Dass das eine SID und dahinter eine Wiedererkennung seinerseits stattfindet, ist ihm egal.
Da es sein kann, dass User in ihrem Browser Cookies deaktiviert haben, muß ich mich jetzt aber darum kümmern, dass sich auch diese User beim Aufruf der nächsten Ressource für eine Session identifizieren können - sprich, dass auch diese User die SID auf den Weg mitbekommen.
Das kann PHP auch selbst erledigen. Da URL-Parameter aber einfacher in fremde Hände gelangen können, hat man diesen Weg mittlerweile nicht mehr per default eingeschaltet. Relevant dafür sind session.use_only_cookies und session.use_trans_sid.
Wenn ich also einen Link von der Session-startenden Seite zu einer nächsten schreibe, dann mache ich das so: [...] Dabei passiert Folgendes: Wenn der User Cookies akzeptiert, wird die Seite als 'nextpage.php?' aufgerufen und die SID im Header, also nicht sichtbar, mitgesendet. Wenn der Browser des Users Cookies nicht akzeptiert, wird die Seite als 'nextpage.php?PHPSESSID=7e7467a2d2...' aufgerufen. Die SID ist somit sichtbar.
Das geschieht nicht automatisch, wenn du das zu Fuß machen willst. In dem Fall musst du auch prüfen, ob ein Session-Cookie vorhanden ist und dementsprechend die URL ändern oder auch nicht.
Das '
htmlspecialchars()' ist eine Sicherheits-Absicherung gegen bösartige Angriffe.Ja, hat aber nicht nur was mit Sessions zu tun, sondern ist bei allen Ausgaben anzuwenden, wenn du nicht absolut sicher bist, dass die keine HTML-relevanten Zeichen enthalten - also im Prinzip alles was in einer Variable steht, deren Inhalt du nicht abolut sicher kennst, muss behandelt werden (Stichwort Kontextwechsel).
1.) Habe ich das Session-Sytsem, zumindest mal den Anfang davon, grundlegend richtig verstanden? Gibt es irgendwelche weiteren Session-Parameter in der php.ini, auf die ich aus bestimmten Gründen achten muß?
In einer Multi-Anwendungen-Umgebung ist es sinnvoll, jeder Anwendung ihren eigenen session.save_path zu spendieren, sonst legen alle ihr Zeug gemeinsam ab und der mit den aggressivsten Garbage-Collection-Einstellungen putzt den anderen die Session-Dateien unabhängig von deren Verständnis von einem Timeout weg.
2.) Was würde denn passieren, wenn in meiner php.ini der Parameter 'session.use_only_cookies' den Wert '0' hätte? Dann würde also die SID nicht nur über den Cookie und weiter dann im Header der nächsten Anfrage zum Client kommen, sondern auch ... wie???
... über URL-Parameter, Hidden-Fields im Formular. Ob der Parameter auch Auswirkungen hat, ob nur im Cookie nach der SID gesucht wird, entzieht sich meiner Kenntnis. Das Handbuch schreibt bei der Parametererläuterung nichts darüber.
Und wenn jetzt zusätzlich auch noch der Parameter 'session.use_cookies' den Wert '0' hätte, dann gäbe es also keinen gesetzten Cookie und das weitere Prozedere wäre ... was???
session.use_cookies sagt, dass überhaupt Cookies zum Transport der SID verwendet werden. session.use_only_cookies gibt an, dass diese ausschließlich verwendet werden. Wenn du ersteres auf 0 setzt, musst du die SID selbständig anderweitig übertragen.
3.) Gegen welche Art von Angriff bzw. Mißbrauch schütze ich mich eigentlich durch die verwendung des '
htmlspecialchars()' beim Anhängen der SID an eine URL?http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel
4.) Bleiben wir bei meiner Konfiguration. Es wird nur mit Cookies gearbeitet - und nehmen wir weiters an, der Browser des Users läßt Cookies zu. Das bedeutet, um bei obigem Beispiel zu bleiben, dass die nächste Seite als 'nextpage.php?' aufgerufen wird. Mich nervt dieses nun sinnlose Fragezeichen am Ende der URL sehr. Muß ich damit leben oder kann ich den Code irgendwie so abändern, dass nur 'nextpage.php' aufgerufen wird, wenn Cookies akzeptiert werden und die SID somit im Header mitgesendet wird?
Du kannst prüfen, ob die SID defined() ist oder nicht und abhängig davon das ? setzen. Ansonsten ist das Fragezeichen völlig harmlos, kein Grund sich davon genervt zu fühlen.
5.) Nicht verstanden habe ich das Beenden einer Session. Wenn ich noch vor dem '
session_start()' ein 'session_set_cookie_params('3600');' setze - was bedeutet das genau? Dass nach 1 Stunde alles weg ist, also die Variablen/Werte im Arry plus Name und wert der ID, so als ob es also nie eine Session gegeben hätte, oder ist das nur die Gültigkeitsdauer des Arrayinhalts?Das ist nur die Cookie-Lebenszeit. Die Session selbst ist davon nicht betroffen. Für die gilt, dass sie mindestens session.gc_maxlifetime lang lebt. Danach darf der Garbage-Collector, der per Zufall zum Sessionstart aufgerufen wird, sie aufräumen. Zuständig für den Zufall sind die 'gc_...'-Werte.
Wenn du die Session-Daten explizit löschen willst, kannst du mit $_SESSION = array(); die Daten entfernen. Dass da noch in Cookies und anderswo die SID rumliegen kann, ist nebensächlich. Prüfe nicht, ob eine Session existiert, sondern ob in $_SESSION die für dich relevanten Daten drinstehen oder nicht. Die SID komplett wegräumen zu wollen ist vegebenen Liebesmüh.
session_destroy() [...]
kannst du zugunsten der Leeres-Array-Methode ignorieren.
Und was genau bedeutet der Parameter 'session.cache_expire' in der php.ini, der bei mir standardmäßg den Wert '180' hat?
Das hat zusammen mit session.cache_limiter nur eine HTTP-Header beeinflussende Funktion. Das gibt an, inwieweit der Browser die Seite in seinem Cache gültig lassen soll. Ist standardmäßig ausgeschaltet, weil man Session-Seiten eigentlich nicht cachen will. Auf die Lebensdauer der Session-Daten hat das keine Auswirkungen.
6.) Bei oben beschriebenen Einstellungen - bin ich auf der sicheren Seite oder ist Arbeiten mit Sessions sehr gefährlich?
SID-Diebstahl fällt mir dazu nur ein, der zu einer Session-Übernahme führen kann. Das kannst aber nicht du allein verhindern. Wenn es wirklich darauf ankommt, vergib zu solch kritischen Aktionen Einmal-IDs. Maßnahmen gegen CSRF können auch gegen Entführungen helfen.
Lo!
-
Hello,
Durch mein '
session_start();' wird also eine Session gestartet bzw. eine schon bestehende wieder aufgenommen. Session bedeutet, dass es ab diesem Zeitpunkt ein Array mit dem Namen '$_SESSION' gibt, in welches ich jetzt beliebig viele Variablen/Werte schreiben kannbegrenzt durch den für Scripte bereitgestellten Arbeitsspeicher. Da dieser meistens nur 8MB betträgt, solltest Du also rechtzeitig aufhören, das Sessionarray mit Daten zu füttern. Sonst kann es Dir nämlich passieren, dass es zwar noch weggeschrieben, nicht aber wiedergeholt werden kann beiom nächsten Request. Mach einfach mal ein paar Versuche und teile uns Deine Erfahrungen mit.
[...] und andere Seiten, die dann mit dieser Session weiterarbeiten,
gewöhne Dir am besten gleich den Begriff "Seiten" ab und benutze stattdessen "Request". Welche Ressource innerhalb der Domain dieser Request anfordert, ist für den Sessionmechanismus erst einmal irrelevant.
auf diese Werte bzw. dieses Array zugreifen können. In dem Moment, wo eine Session gestartet wird, vergibt der Server auch ein Erkennungsmerkmal für diese Session, damit sie identifiziert werden kann. Dieses Erkennungsmerkmal ist die SID.
Standartmäßig
standardmäißg
hat die SID den Namen 'PHPSESSID' und einen (durch Zufallsgenerator entstandenen?) eindeutigen Wert, der vom Server, auf dem PHP läuft, vergeben wird. Der Name der SID wird ebenfalls durch die php.ini geregelt, nämlich durch den Parameter 'session.name'. Habe ich das soweit richtig verstanden?
Du kannst den Namen auch selber setzen im Script, wenn Du session_name() benutzt, bevor Du session_start() aufrufst. So können in einem Request-Handler auch mehrere Sessiondateienn gleichzeitig verwendet werden.
In meiner php.ini haben die Parameter 'session.use_cookies' und 'session.use_only_cookies' beide den Wert '1'. Das bedeutet, dass der Wert meiner SID automatisch durch ein Cookie beim Client hinterlegt wird.
... dass der Server in seiner Response automatisch die Session-ID als Cookie mitsendet. Ob er vom Client akzeptiert wird, entscheidet der Client.
Ruft nun der Client eine weitere php-Ressource ab, dann sendet er in der Anfrage dafür im Header automatisch den Wert der SID mit.
Er sendet das Name-Value-Pärchen für denn Cookie mit.
Bildlich gesprochen: Er sagt dem Client:
... der Client fordert den Server auf
Nun parse mir bitte die Ressource 'foo.php' ... and by the way ... ich bin der Kunde mit der SID 'bar'. Somit erkennt mich der Server und schickt mir die Ressource 'foo.php' inclusive aller Werte/Variablen des dieser Session dazugehörenden Arrays '$_SESSION'.
Der Server kann die passenden Sessiondaten wiederherstellen und sie in die Auswertung des Requests einfließen lassen. Er behält aber die Daten für sich, wenn Du nicht im Script ausdrücklich etwas anderes (echo ...) bestimmt hast.
Da es sein kann, dass User in ihrem Browser Cookies deaktiviert haben, muß ich mich jetzt aber darum kümmern, dass sich auch diese User beim Aufruf der nächsten Ressource für eine Session identifizieren können - sprich, dass auch diese User die SID auf den Weg mitbekommen.
Du kannst Dich darum kümmern. Du kannst das aber auch getrost PHP überlassen. Dann setze eben nicht den Konfigurationsparameter session.use_only_cookies auf 1 und erlaube die Nutzung einer transparenten SID http://de.php.net/manual/de/session.configuration.php#ini.session.use-trans-sid
PHP baut dann in die erste Response nach dem ersten session_start(), wenn also in keinem der drei Arrays $_COOKIE, $_POST und $_GET eine Session-ID zu finden war, sowohl einen Cookie ein, als auch die transparente SID in alle Formulare als Hidden-Element, in alle Links auf die eigene Domain als Get-Parameter. Das geht erfreulicherweise ganz automatisch, wenn Du es zulässt.
Wenn ich also einen Link von der Session-startenden Seite zu einer nächsten schreibe,
Wenn du eine neue Request-URi baust und in die response einsetzt...
dann mache ich das so:
Dann lasse es PHP für dich tun. :-))
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
ein Array mit dem Namen '$_SESSION' gibt, in welches ich jetzt beliebig viele Variablen/Werte schreiben kann
begrenzt durch den für Scripte bereitgestellten Arbeitsspeicher. Da dieser meistens nur 8MB betträgt,Meinst du die Limitierung durch memory_limit, welcher aktuell (PHP 5.3) einen Default-Wert von 128 MB hat?
Standartmäßig
standardmäißgNicht ganz. :-)
Du kannst Dich darum kümmern. Du kannst das aber auch getrost PHP überlassen. Dann setze eben nicht den Konfigurationsparameter session.use_only_cookies auf 1
Nee, auf 0.
und erlaube die Nutzung einer transparenten SID http://de.php.net/manual/de/session.configuration.php#ini.session.use-trans-sid
Das muss die 1 bekommen.
Lo!
-
Hi Tom, hi dedlfix,
zunächst mal Danke für Eure Antworten. Ich muß mich jetzt mal Step-By-Step damit beschäftigen, da ich das wirklich verstehen möchte.
OK, also wenn 'session.use_trans_sid' in der php.ini den Wert '1' hat, kümmert sich PHP um das Anhängen der SID, wenn Cookies deaktiviert sind.
Stimmt. Das habe ich vorher nicht gesehen bzw. richtig umgesetzt. Allerdings weicht mein Test von Euren Aussagen ab. Also bei folgenden Voraussetzungen:
PHP Version: 5-53STABLE-STANDARD
php.ini => session.use_cookies : 1
session.use_only_cookies : 1
session.use_trans_sid : 1passiert genau das, was ich möchte. Bei einem
<a href="foo.php">bar</a>wird (getestet allerdings nur mit Firefox, Version 3.6.11) bei ausgeschalteten Cookies "foo.php?PHPSESSID=a69a...." und bei eingeschalteten Cookies ein "foo.php" aufgerufen. Ohne Fragezeichen.Das weicht jedoch von Tom's Anweisung, ich soll für 'session.use_only_cookies' den Wert auf '0' setzen, ab. Ist das nur ein Zufall, dass das gerade in dieser Situation funktioniert und ich soll 'session.use_only_cookies' trotzdem abschalten - oder hat sich die Aussage auf ältere PHP Versionen bezogen?
MfG
Hugo E.B.
-
Hello,
php.ini => session.use_cookies : 1
session.use_only_cookies : 1
session.use_trans_sid : 1session.use_only_cookies : 0
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi Tom,
session.use_only_cookies : 0
du hast meinen Beitrag nicht wirklich gelesen jetzt, oder? Ich weiß schon, dass du das vorher gesagt hast und ich hatte geschrieben, dass es mit besagter Kombination funktioniert und gefragt, ob das ein Zufall ist oder nicht.
MfG
Hugo E.B.
-
Hello,
session.use_only_cookies : 0
du hast meinen Beitrag nicht wirklich gelesen jetzt, oder? Ich weiß schon, dass du das vorher gesagt hast und ich hatte geschrieben, dass es mit besagter Kombination funktioniert und gefragt, ob das ein Zufall ist oder nicht.
Doch, ich habe ihn gelesen.
Du siehst mich hier aber auch etwas ratlos im Moment. Das Verhalten in dieser Angelegenheit ist quasi gewachsen mit jeder neuen PHP-Version und ich kann keine verlässliche Aussage treffen, welche sich wie verhält.
Nach meinem Verständnis (und dem Manual) sollte "session.use_only-cookies" eigentlich die Oberhand behalten. Ein eingeschaltetes "session.use_trans_sid" sollte dagegen verlieren...
Aber was funktioniert schon so, wie es logisch erklärbar wäre?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Hi!
PHP Version: 5-53STABLE-STANDARD
Hier solltest du nochmal genau nachsehen, denn das ist eine seltsame Versionsnummer. Aktuell wäre 5.3.3. Wenn irgendwelche Distributionen ihr eigenes Nummerierungsschema (und vielleicht spezifische Patche) verwenden, dann nützt die von der offiziellen Versionsnummer abweichende Zusatzinformation ohne den Distributionsnamen recht wenig. Wie auch immer, meistens ist die Versionsnummer auf drei Stellen genau (x.y.z) eine völlig ausreichende Information.
php.ini => session.use_cookies : 1
session.use_only_cookies : 1
session.use_trans_sid : 1passiert genau das, was ich möchte. Bei einem
<a href="foo.php">bar</a>wird (getestet allerdings nur mit Firefox, Version 3.6.11) bei ausgeschalteten Cookies "foo.php?PHPSESSID=a69a...." und bei eingeschalteten Cookies ein "foo.php" aufgerufen. Ohne Fragezeichen.Dein Versuch ergab dann ein anderes Ergebnis als mein Versuch (mit PHP 5.3.3). Mit session.use_only_cookies=1 bekomme ich keine URL-Anhänge, egal wie session.use_trans_sid steht (alles andere hätte mich sehr gewundert).
Das weicht jedoch von Tom's Anweisung, ich soll für 'session.use_only_cookies' den Wert auf '0' setzen, ab. Ist das nur ein Zufall, dass das gerade in dieser Situation funktioniert und ich soll 'session.use_only_cookies' trotzdem abschalten - oder hat sich die Aussage auf ältere PHP Versionen bezogen?
Prüf das noch einmal. Ansonsten spräche ja nichts dagegen, es einfach so einzusetzen, wie es zum einen deinem Wunsch entspricht und zum anderen richtig wäre, anstatt was falsches zu konfigurieren und zu hoffen, dass es trotzdem wie gewünscht funktioniert.
Lo!
-
-
-
Hi Tom,
Standartmäßig
standardmäißgAlso wenn Du mich schon verbesserst, dann mache es doch wenigstens richtig. *g* Und wenn wir schon dabei sind...
Du kannst den Namen auch selber setzen ...
Man schreibt "selbst", nicht "selber", das sagt sogar der Zwiebelfisch. (Siehe Frage von Marie Nienhaus)
Er sendet das Name-Value-Pärchen für denn Cookie mit.
Für _denn_ Cookie? Na da wird _err_ sich aber freuen. ;-)
Liebe Grüße
Hugo E.B.
-
Hello,
Also wenn Du mich schon verbesserst,
kann ich Dich denn überhaupt verbessern? Das sollte mich freuen!
Aber die Berichtigung der Berichtigung nehme ich gerne entgegen ;-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-