nicht angemeldet
Session beenden?
Hallo!
Wie beende ich eine Session, die ich mit session_start() ins Leben gerufen habe? Ich habe nur session_unregister gefunden, aber die entfernt na nur die Variablen aus einer Session (habe ich überall so gelesen). Heisst das, dass die Session damit auch beendet ist oder nicht?
Ich brauche die Sessions nämlich für ein Forum und wenn sich jemand ausloggt, soll die Session ja gelöscht werden.
MfG, muenzchen
-
Ich schätze mal, du suchst nach session_destroy().
Hier ein Link..:
http://www.php.net/manual/en/function.session-destroy.php-
Ich schätze mal, du suchst nach session_destroy().
Hier ein Link..:
http://www.php.net/manual/en/function.session-destroy.phpgenau das hab ich gesucht. Muss den Wald vor lauter Bäumen nicht gesehen haben, dabei habe ich extra in Selfphp nachgesehen.
Danke! :)
MfG, muenzchen
-
-
Hallo,
Ich erklärs nur für Temp.Cookies=on, weil ich andere Sessions (mit Ausnahme selbstgebauter mit Auth) für blödsinn halte:
Die Session wird beendet, indem man ihr den Cookie klaut. Das kann man einfach durch
session_start(); // Session initialisieren mit Hilfe von $_COOKIE["PHPSESSID"]
session_destroy(); // Sessiondatei löschen
setcookie("PHPSESSID"); // Cookie auf dem Client vernichtenbeide Sessionfunktionen greifen auf den Cookie mit dem Sessionnamen im Array $_COOKIE[] zu.
Wenn man den Cookie auf dem Client nicht ebenfalls vernichtet, ist der in $_COOKIE["PHPSESSID"] beim nächsten Request wieder da und es wird, mangels vorhandener Sessiondatei eine neue Sessiondatei unter der alten Nummer angelegt.
Daher beendet man eine Session keinesfalls alleine durch session_destroy().
Es reicht im Prinzip, einen leeren Cookie an den Client zu senden. Die letzten Sessiondaten bleiben dann aber solange erhalten, bis der Garbage Collector sie beseitigt hat.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo!
Ich erklärs nur für Temp.Cookies=on, weil ich andere Sessions (mit Ausnahme selbstgebauter mit Auth) für blödsinn halte:
Ich weiß, das Thema ist durch, aber ich möchte doch darauf hinweisen dass es für Sessions auch andere Anwendungsgebiete gibt außer einer Authentifizierung, Cookies haben Vor- und Nachteile, genau so URL-Rewriting.
session_destroy(); // Sessiondatei löschen
setcookie("PHPSESSID"); // Cookie auf dem Client vernichtenErsterer Befehl ist der von PHP vorgesehene um eine Session zu beenden(Die Session-Daten auf dem Server zu löschen), ob Cockie oder URL-Rewriting, letzterer löscht den Cockie, was wie Du richtig sagst bei Cockies der sicherste Weg ist, da destroy in Ausnahmefällen nicht korrekt funktioniert, siehe
http://www.php3.de/manual/de/function.session-destroy.php
http://www.dclp-faq.de/q/q-sessions-loeschen.htmlWenn man den Cookie auf dem Client nicht ebenfalls vernichtet, ist der in $_COOKIE["PHPSESSID"] beim nächsten Request wieder da und es wird, mangels vorhandener Sessiondatei eine neue Sessiondatei unter der alten Nummer angelegt.
ja und? Es kommt drauf an wozu und wie man die Session verwendet. PHP erstellt nur eine neue Session nach einem session_start(), was aber nicht vorkomen sollte wenn man eine Session gelöscht hat, es sei denn man möchte explizit eine neue, leere Session starten, dann ist es auch egal das es dieselbe SessionID ist. Bei einer Authentifizierung gelten andere Regeln - ich weiß - aber dazu werden Sessions eher selten verwendet.
Meiner Meinung nach verwirren derartige Aussagen jemanden der sich nicht so sehr mit der Materie auskennt wie Du.
Viele Grüße
Andreas-
Hallo,
Vorab: münzchen, bist Du verwirrt?
@Andreas...
Ich weiß, das Thema ist durch, aber ich möchte doch darauf hinweisen dass es für Sessions auch andere Anwendungsgebiete gibt außer einer Authentifizierung, Cookies haben Vor- und Nachteile, genau so URL-Rewriting.
Das musst Du mir mal näher erklären! Der einzige Zweck der Session ist doch, den Client eindeutig wiederzuerkennen von Request zu Request, um ihm die richtigen Daten zuzuleiten. Was sollte denn sonst der Anwendungsfall für Sessions sein? Und diese Wiedererkennung kann man nun ganz einfach halten, man kann vorher darüber nachdenken, was man tut, und man kann auch den durchaus vertretbaren Aufwand einer Echtheitsprüfung für die Session durchführen. Das hat alles noch nichts mit einer "Authentifizierung" von in Nutzerkonten registrierten Nutzern zu tun.
Die kann man zusätzlich durchführen.
session_destroy(); // Sessiondatei löschen
setcookie("PHPSESSID"); // Cookie auf dem Client vernichten
Ersterer Befehl ist der von PHP vorgesehene um eine Session zu beenden(Die Session-Daten auf dem Server zu löschen), ob Cockie oder URL-Rewriting, letzterer löscht den Cockie, was wie Du richtig sagst bei Cockies der sicherste Weg ist, da destroy in Ausnahmefällen nicht korrekt funktioniert, siehe
http://www.php3.de/manual/de/function.session-destroy.php
http://www.dclp-faq.de/q/q-sessions-loeschen.htmlJa ich weiß, darum habe ichs gesagt.
Wenn man den Cookie auf dem Client nicht ebenfalls vernichtet, ist der in $_COOKIE["PHPSESSID"] beim nächsten Request wieder da und es wird, mangels vorhandener Sessiondatei eine neue Sessiondatei unter der alten Nummer angelegt.
ja und? Es kommt drauf an wozu und wie man die Session verwendet. PHP erstellt nur eine neue Session nach einem session_start(), was aber nicht vorkomen sollte wenn man eine Session gelöscht hat, es sei denn man möchte explizit eine neue, leere Session starten, dann ist es auch egal das es dieselbe SessionID ist. Bei einer Authentifizierung gelten andere Regeln - ich weiß - aber dazu werden Sessions eher selten verwendet.
Ich möchte niemals gezwungen sein, mein Leben oder auch nur meine Gesundheit einem DEINER Programme anvertrauen zu müssen. Deine ganzen Aussagen zui diesem Thema deuten immer wieder darauf hin, dass Du Dir über Fehlertoleranz noch nie Gedanken gemacht hast, oder aber das Wort falsch verstanden hast.
Also nochmal zum Mitschreiben: Programme mit hoher Fehlertoleranz sind solche, die auf Übertragungsfehler, Benutzerfehler etc. intelligent reagieren können und es bedeutet NICHT, dass jede Schlampigkeit oder Faulheit des Programmierers zu tolerieren ist.
Meiner Meinung nach verwirren derartige Aussagen jemanden der sich nicht so sehr mit der Materie auskennt wie Du.
Meiner Meinung nach kann Derjenige ja nachfragen, wenn es ihn verwirrt hat. Wie "er" (also Münzchen, du bist hier gemeint) ja unschwer erkennen kann, bin ich öfer hier.
Ermahnende Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo!
Das musst Du mir mal näher erklären! Der einzige Zweck der Session ist doch, den Client eindeutig wiederzuerkennen von Request zu Request, um ihm die richtigen Daten zuzuleiten.
sehr richtig.
Was sollte denn sonst der Anwendungsfall für Sessions sein?
ich habe genau obiges gemeint.
Und diese Wiedererkennung kann man nun ganz einfach halten,
wie das die meisten Leute(PHP-Anwender) machen...
man kann vorher darüber nachdenken, was man tut,
das habe ich auch, dank Dir sogar mehrfach und tiefer als ich es je sonst gemacht hätte
und man kann auch den durchaus vertretbaren Aufwand einer Echtheitsprüfung für die Session durchführen.
was ist das? PHP prüft selbst ob vom Client eine gültige SessionID übermitelt wurde. Ich kenne auch das problem mit vor und zurück, daher funktionieren viele Sesion-basierte Seiten nicht korrekt, da dies bei der Benutzerführung nicht bedacht wurde. Ich stimme auch vollkommen überein das Cockies besser geeignet sind, aber es gibt genügend Anwendungsfälle wo es wichtiger ist Besucher(Kunden) nicht bzgl. Browsereinstellung(Cockies an) zu bevormunden, sondern diejenigen die Cockies deaktiviert haben(je nach Klientel mehr oder weniger) mit dem vor/zurück Problem zu "belasten". Dafür gibt es ja Trans-SID, die miesten Besucher haben somit keine Probleme, die anderen sind selbst schuld dass sie keine Cockies verwenden wollen und müssen dann auch mit den Konsequenzen leben. Die Leute kenne meist das Problem und werden im Fall eines Verlustes Ihrer Session wissen wieso das passiert ist, aus Erfahrung. Bei einer typischen Anwendung wie einem Warenkorb ist dieses "Risiko" in vielen Fällen durchaus gerechtfertigt, wie ich finde. Ich wollte nicht alle Käufer ausschließen die keine Cockies verwenden möchten - aus welchen Gründen auch immer.
Das hat alles noch nichts mit einer "Authentifizierung" von in Nutzerkonten registrierten Nutzern zu tun.
Jepp.
Ich möchte niemals gezwungen sein, mein Leben oder auch nur meine Gesundheit einem DEINER Programme anvertrauen zu müssen.
Das verlangt auch keiner von Dir ;-) Bei Warenkörben & Co. geht es aber meist nicht um Leben und Tod, da gelten andere Voraussetzungen. Und gerade sowas sind doch die Standard-Anwendungen für Sessions, oder?
Deine ganzen Aussagen zui diesem Thema deuten immer wieder darauf hin, dass Du Dir über Fehlertoleranz noch nie Gedanken gemacht hast, oder aber das Wort falsch verstanden hast.
ich bin kein Informatiker, aber ich weiß zu unterscheiden wo ich welche Anforderung an die Fehlertoleranz stellen sollte, zumindest für mein Verständnis.
Also nochmal zum Mitschreiben: Programme mit hoher Fehlertoleranz sind solche, die auf Übertragungsfehler, Benutzerfehler etc. intelligent reagieren können und es bedeutet NICHT, dass jede Schlampigkeit oder Faulheit des Programmierers zu tolerieren ist.
Wie oben beschreiebn gibt es auch andere Arggumente die wichtiger sein können, das kommt wie gesagt auf die spezielle Anwendung an. Bei einer Authentifizierung würde ich das niemals so machen, unter anderem aus diesen Gründen, aber auch aus anderen.
Ermahnende Grüße aus http://www.braunschweig.de
Wird man jetzt schon ermahnt wenn man nicht Deiner Meinung ist? Es tut mir Leid, aber in einigen Punkten teile ich Deine Ansicht bzgl. Sessions nunmal nicht. Aber gerade durch verscheidenen Ansichten entstehen IMHO interessante Diskussionen, oder nicht?
Viel Grüße
Andreas-
Und noch ein Hallo,
und man kann auch den durchaus vertretbaren Aufwand einer Echtheitsprüfung für die Session durchführen.
was ist das? PHP prüft selbst ob vom Client eine gültige SessionID übermitelt wurde.PHP kann nicht prüfen, ob die gesendete Sessionnummer eine echte oder eine gefälschte Sessionnummer ist, wenn man nicht ein zweites Kriteium einführt. In Netzen ist das entweder die connection-number oder eben in verbindungslosen Netzen ein zweiter Schlüssel. PHP kann mit einem Schlüssel, also z.B. der Sessonnummer, nur prüfen, on der Schlüssel zufällig irgendwo passt.
Ermahnende Grüße aus http://www.braunschweig.de
Wird man jetzt schon ermahnt wenn man nicht Deiner Meinung ist? Es tut mir Leid, aber in einigen Punkten teile ich Deine Ansicht bzgl. Sessions nunmal nicht. Aber gerade durch verscheidenen Ansichten entstehen IMHO interessante Diskussionen, oder nicht?Das hat hier nichts mit meiner Meinung zu tun. Es gibt schlaue Professoren, die sich das alles ausgedacht haben und das schon vor über 150 Jahren. Vielleicht haben sogar schon die Pyramidenbauer über Echtheit von Schlüsseln nachgedacht, denn sonst hätten sie nicht soviele Geheimtüren (das Wissen, wo sie ist, ist auch ein Schlüssel) oder Virenattacken zusätzlich eingebaut. Warum ignoroerst Du dieses Wissen?
Trotzdem natürlich ganz liebe Grüße aus http://www.braunschweig.de
Ohne unseren Dauerdisput würde mir sowieso was fehlen :-))
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo!
PHP kann nicht prüfen, ob die gesendete Sessionnummer eine echte oder eine gefälschte Sessionnummer ist, wenn man nicht ein zweites Kriteium einführt. In Netzen ist das entweder die connection-number oder eben in verbindungslosen Netzen ein zweiter Schlüssel. PHP kann mit einem Schlüssel, also z.B. der Sessonnummer, nur prüfen, on der Schlüssel zufällig irgendwo passt.
Du _willst_ mich nicht verstehen, oder? Es ist _vollkommen_ außer Frage dass die standardmäßige Prüfung von PHP dieses Risiko birgt, die Frage ist wie hoch dieses Risiko ist, und ob es Anwendungen gibt, wo dieses Risko zugunsten anderer Argumente tragbar sein kann, wie Warenkörbe oder Boards.
Das hat hier nichts mit meiner Meinung zu tun. Es gibt schlaue Professoren, die sich das alles ausgedacht haben und das schon vor über 150 Jahren. Vielleicht haben sogar schon die Pyramidenbauer über Echtheit von Schlüsseln nachgedacht, denn sonst hätten sie nicht soviele Geheimtüren (das Wissen, wo sie ist, ist auch ein Schlüssel) oder Virenattacken zusätzlich eingebaut. Warum ignoroerst Du dieses Wissen?
Ich dene nicht das dieses Wissen 1:1 übertragbar ist. Damals gab es keine Browsr die Cookies abschalten können! Der technisch opimale Weg ist nicht immer der beste um ans Ziel zu kommen!
Trotzdem natürlich ganz liebe Grüße aus http://www.braunschweig.de
Ohne unseren Dauerdisput würde mir sowieso was fehlen :-))
Gib mir Recht und ich geb Ruhe ;-)))
Grüße
Andreas-
Hi,
[...] <-- viel Text rausgeschnitten
Ohne unseren Dauerdisput würde mir sowieso was fehlen :-))
Gib mir Recht und ich geb Ruhe ;-)))Das könnte Dir so passen. Dann gehen mir ja die "anderen" Denkansätze verloren. *gg*
Liebe Grüße aus http://www.braunschweig.deTom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo Tom!
Ohne unseren Dauerdisput würde mir sowieso was fehlen :-))
Gib mir Recht und ich geb Ruhe ;-)))Das könnte Dir so passen. Dann gehen mir ja die "anderen" Denkansätze verloren. *gg*
Liebe Grüße aus http://www.braunschweig.deNochmal einer meiner berühmten Äpfel-Birnen Vergleiche:
Wenn ich in einer Videothek ein Video ausleihe, reicht denen auch die Vrolage eines tierisch einach zu fälschenden Papier-Kundenausweises. Da wäre es viel sicherer jedesmal den Personal-Ausweis zu verlangen, oder am besten direkt einen genetischen Fingerabdruck zu überprüfen. Das wäre dann sehr sicher, aber wenn die das machen würden wären sie bald Pleite da kein Mensch das mitmachen würde. In diesem Fall ist der "Unsichere" Papier-Ausweis hinreichend sicher, und das Argument der Bequemlichkeit überwiegt hier. Genauso sehe ich das bei Warenkörben und Boards.
Grüße
Andreas
-
-
-
-
-
-
-