Session löschen

[Patrick]

Hallo,

Ich habe einiges zu Sessions, das ich noch nicht so recht verstehe.

Ich schreibe gerade an einem Onlineshop, bei dem es keine Benutzerregistrierung/Login gibt. Wann also soll ich die erstellten Sessions löschen? Dem User ein "Session löschen" anbieten finde ich nicht sinnvoll.

Zum zweiten: Was mache ich mit Kunden, bei denen Cookies deaktiviert sind (Browsereinstellungen oder Firewall)? Ich habe gelesen, dass es zu unsicher sei, die Session-Id in der URL zu übergeben. Wieso? Es wird wohl kaum jemand eine schon bestehende Session_Id erraten können.

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?
Als Beispiel: Jemand betritt die Startseite (wo noch keine PHPSESSID dabei ist), und der drückt einige Male auf "Refresh". Schon habe ich mehrere Sessions, die Ewigkeiten halten können. Bei einem sehr gut besuchten Onlineshop geht das schon ins gewicht.

Kann mir jemand helfen? Vielen Dank, Patrick

[Lude]

Hi,

Ich schreibe gerade an einem Onlineshop, bei dem es keine Benutzerregistrierung/Login gibt.

"Warum nicht?", frage ich da einfach mal spasseshalber.

Wann also soll ich die erstellten Sessions löschen?

Gar nicht. Die timen aus.

Dem User ein "Session löschen" anbieten finde ich nicht sinnvoll.

Brrr   ;-)
Aber ein Ausloggen, was ja letztlich auf eine Ruecknahme der Sitzungsauthetifizierung hinauslaeuft, ist schon OK.

Zum zweiten: Was mache ich mit Kunden, bei denen Cookies deaktiviert sind (Browsereinstellungen oder Firewall)?

Sitzungskonzepte ohne Cookies nutzen.

Ich habe gelesen, dass es zu unsicher sei, die Session-Id in der URL zu übergeben. Wieso? Es wird wohl kaum jemand eine schon bestehende Session_Id erraten können.

Im Prinzip schon richitg, erraten nicht, aber "abhoeren".

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?

Per Job einmal naechtlich?

Als Beispiel: Jemand betritt die Startseite (wo noch keine PHPSESSID dabei ist), und der drückt einige Male auf "Refresh". Schon habe ich mehrere Sessions, die Ewigkeiten halten können. Bei einem sehr gut besuchten Onlineshop geht das schon ins gewicht.

s.o.

Gruss,
Lude

[Patrick]

Hi,

Ich schreibe gerade an einem Onlineshop, bei dem es keine Benutzerregistrierung/Login gibt.

"Warum nicht?", frage ich da einfach mal spasseshalber.

Ganz einfach, weil der Auftraggeber das so will :P

Wann also soll ich die erstellten Sessions löschen?

Gar nicht. Die timen aus.

Dem User ein "Session löschen" anbieten finde ich nicht sinnvoll.

Brrr   ;-)
Aber ein Ausloggen, was ja letztlich auf eine Ruecknahme der Sitzungsauthetifizierung hinauslaeuft, ist schon OK.

Aber bei ein "Logout" Button würde ich schon stutzen wenn ich mich nie eingeloggt habe...

Zum zweiten: Was mache ich mit Kunden, bei denen Cookies deaktiviert sind (Browsereinstellungen oder Firewall)?

Sitzungskonzepte ohne Cookies nutzen.

OK :)

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?

Per Job einmal naechtlich?

Wie bitte?

Gruß, Marko

[Lude]

Hi,

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?

Per Job einmal naechtlich?

Wie bitte?

ich weiss ja nicht, was bei Dir laeuft. Ich praeferiere Sitzungskonzepte mit Sitzungen, die mehrere Zeitstempel haben. Ob eine Sitzung ausgetimt ist, ermittele ich bei jedem Datenzugriff. Dann ist zwischen dem physikalisch angelegten Datensatz und einer nicht ausgetimten Sitzung keine "1:1-Beziehung". D.h. ich loesche die Sitzungen, wenn das System Zeit hat, also z.B. einmal in der Nacht.

Gruss,
Lude

[Tom]

Hello,

Ich schreibe gerade an einem Onlineshop, bei dem es keine Benutzerregistrierung/Login gibt. Wann also soll ich die erstellten Sessions löschen? Dem User ein "Session löschen" anbieten finde ich nicht sinnvoll.

Das ist eine gute Frage. Die Sessiondateien werden bei PHP parallel zu allen anderen Aktionen vom GC (Garbage Collector) eingesammelt = gelöscht. Dieser wird durch session_start() als Childprozess im Hintergrund angestoßen. Typisch nach 1440 Sekunden Nichtbenutzung der Sessiondatei.

Ein Kunde, der sich nicht bewusst logged hat, wird auch kein Verständnis für "Abmelden" aufbringen.

Zum zweiten: Was mache ich mit Kunden, bei denen Cookies deaktiviert sind (Browsereinstellungen oder Firewall)?

Das müsste sich dann schon um eine Applikation-Firewall handeln, die in den Strem der HTTP-Daten eingreift. Browser wehren sich schon öfter...

Ich habe gelesen, dass es zu unsicher sei, die Session-Id in der URL zu übergeben. Wieso? Es wird wohl kaum jemand eine schon bestehende Session_Id erraten können.

Doch theoretisch schon. je mehr Sessions laufen, desto leichter.  Aber finden kann er sie in Logs, per emial versandten Websites, etc.

Man könnte durch vorheriges Versenden eines Cookies testen, ob dieser angenommen wird. Wen nicht, kann man den User darauf aufmerksam machen, dass das "Warenkorbsystem" (Cookies)  seines PCs nicht eingeschaltet ist.

Man benötigt für einen Anonymous-Shop aber überhaupt keine Sessions, da man die Daten wunderbar per Post von einem zum nächsten Formular weitertragen kann.

-> Datenarray
  -> serialize()
  -> base64_encode()
  -> Hidden Field
  -> base64_decode()
  -> unserialize()
  -> Datenarray

Das klappt ganz vorzüglich. Preise muss man natürlich immer wieder neu kontrollieren. Aber Artikelnummern zu faken hat i.d.R. für den User keinen Nutzen...

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?

Die wird automatisch gelöscht.

Als Beispiel: Jemand betritt die Startseite (wo noch keine PHPSESSID dabei ist), und der drückt einige Male auf "Refresh". Schon habe ich mehrere Sessions, die Ewigkeiten halten können. Bei einem sehr gut besuchten Onlineshop geht das schon ins gewicht.

Nein. Das passiert nur, wenn der Knabe keine Cookies annimmt. Und das testet man eben vorher.

Kann mir jemand helfen?

Ja, gerne.

Grüße

Tom

[Patrick]

Hi,

Ich schreibe gerade an einem Onlineshop, bei dem es keine Benutzerregistrierung/Login gibt. Wann also soll ich die erstellten Sessions löschen? Dem User ein "Session löschen" anbieten finde ich nicht sinnvoll.

Das ist eine gute Frage. Die Sessiondateien werden bei PHP parallel zu allen anderen Aktionen vom GC (Garbage Collector) eingesammelt = gelöscht. Dieser wird durch session_start() als Childprozess im Hintergrund angestoßen. Typisch nach 1440 Sekunden Nichtbenutzung der Sessiondatei.

Hmm das ist gar nicht gut, ich selber brauche ab und an länger als eine halbe Stunde um mir einen Warenkorb zusammenzustellen (wenn ich z.B. das Browserfenster ein paar Stunden offen lässe während ich mich irgendwo berate...). Wenn ich dann wiederkomm, würd ichs gar nicht schön finden, alles gelöscht vorzufinden (passiert aber nie).

Ein Kunde, der sich nicht bewusst logged hat, wird auch kein Verständnis für "Abmelden" aufbringen.

Eben

Zum zweiten: Was mache ich mit Kunden, bei denen Cookies deaktiviert sind (Browsereinstellungen oder Firewall)?

Das müsste sich dann schon um eine Applikation-Firewall handeln, die in den Strem der HTTP-Daten eingreift. Browser wehren sich schon öfter...

Ich habe gelesen, dass es zu unsicher sei, die Session-Id in der URL zu übergeben. Wieso? Es wird wohl kaum jemand eine schon bestehende Session_Id erraten können.

Doch theoretisch schon. je mehr Sessions laufen, desto leichter.  Aber finden kann er sie in Logs, per emial versandten Websites, etc.

Das heisst, ich unterstütze nunmal nur Kunden, die Cookies haben?

Man könnte durch vorheriges Versenden eines Cookies testen, ob dieser angenommen wird. Wen nicht, kann man den User darauf aufmerksam machen, dass das "Warenkorbsystem" (Cookies)  seines PCs nicht eingeschaltet ist.

Wie macht man das genau?

Man benötigt für einen Anonymous-Shop aber überhaupt keine Sessions, da man die Daten wunderbar per Post von einem zum nächsten Formular weitertragen kann.

-> Datenarray
  -> serialize()
  -> base64_encode()
  -> Hidden Field
  -> base64_decode()
  -> unserialize()
  -> Datenarray

Ist mir aber zu umständlich, bei jedem Link eine Javascript-Zeile hinzuzufügen, der den Submit eines Formulars mimt (was natürlich bei ausgeschalteten JS auch nicht gut ist ;)).

Wenn ich die URL-Unterstützung einbaue, wie kann ich die Anzahl Sessions in Grenzen halten/wann soll ich die bestehende Session löschen?

Die wird automatisch gelöscht.

S.o.
Wann wird denn die gelöscht? Ich möchte auf keinen Fall, dass die Sessions gelöscht werden, während sie theoretisch noch gebraucht werden (auch wenn sie vom User praktisch ein paar Stunden liegengelassen werden).

Als Beispiel: Jemand betritt die Startseite (wo noch keine PHPSESSID dabei ist), und der drückt einige Male auf "Refresh". Schon habe ich mehrere Sessions, die Ewigkeiten halten können. Bei einem sehr gut besuchten Onlineshop geht das schon ins gewicht.

Nein. Das passiert nur, wenn der Knabe keine Cookies annimmt.

Ich weiss, deswegen frage ich ja ;)

Und das testet man eben vorher.

Ok, bin überzeugt.

Vielen Dank!

Patrick

[Tom]

Hello,

Hmm das ist gar nicht gut, ich selber brauche ab und an länger als eine halbe Stunde um mir einen Warenkorb zusammenzustellen (wenn ich z.B. das Browserfenster ein paar Stunden offen lässe während ich mich irgendwo berate...). Wenn ich dann wiederkomm, würd ichs gar nicht schön finden, alles gelöscht vorzufinden (passiert aber nie).

Man könnte durch vorheriges Versenden eines Cookies testen, ob dieser angenommen wird. Wen nicht, kann man den User darauf aufmerksam machen, dass das "Warenkorbsystem" (Cookies)  seines PCs nicht eingeschaltet ist.

Wie macht man das genau?

Du sendest einen Cookie mit setCookie() und einen zusätzlichen Header("Location: http://start.php");

Dann kannst Du auf der Seite start.php schauen, ob der Cookie angekommen ist. Man sollte natürlich dafür sorgen, dass start.php nicht direkt aufgerufen wird. Kann man nicht unbedingt vermeiden, also kann man gleich einen Selbstbezug aufbauen. Aber Vorsicht! Das gibt einen "Kurzschluss". Da muss man dann mindesten einen Parameter mitgeben, der Aufschluss darüber gibt, ob die Umleitung schon stattgefunden hat.

Man benötigt für einen Anonymous-Shop aber überhaupt keine Sessions, da man die Daten wunderbar per Post von einem zum nächsten Formular weitertragen kann.

-> Datenarray
  -> serialize()
  -> base64_encode()
  -> Hidden Field
  -> base64_decode()
  -> unserialize()
  -> Datenarray

Ist mir aber zu umständlich, bei jedem Link eine Javascript-Zeile hinzuzufügen, der den Submit eines Formulars mimt (was natürlich bei ausgeschalteten JS auch nicht gut ist ;)).

-------------------------------------------------------
    Wer spricht denn von JavaScript? Das geht total ohne!
   -------------------------------------------------------

Wann wird denn die gelöscht? Ich möchte auf keinen Fall, dass die Sessions gelöscht werden, während sie theoretisch noch gebraucht werden (auch wenn sie vom User praktisch ein paar Stunden liegengelassen werden).

Da gibts neu eine Lösung: nur authentifizierte Kunden annehmen. Wäre mir sowieso viel sicherer wegen Belehrung, Rücktritt, Fake-Bestellungen etc. Denen kann man dann eine feste Session-ID zuordnen, die niemals gelöscht wird. Dann muss man aber einen zusätzlichen Login-In PIN vergeben. (@Sven: *pssst* Irgendwann verstehst Du meine Logik auch noch :-))) )

Conclusion:
Für nicht authentifizierte Kunden ist eine Session "Kanonen auf Spatzen". Da reicht die Methode mit dem HiddenField vollkommen.

Grüße

Tom

[Marko]

Hi,

-------------------------------------------------------
    Wer spricht denn von JavaScript? Das geht total ohne!
   -------------------------------------------------------

Wann wird denn die gelöscht? Ich möchte auf keinen Fall, dass die Sessions gelöscht werden, während sie theoretisch noch gebraucht werden (auch wenn sie vom User praktisch ein paar Stunden liegengelassen werden).

Da gibts neu eine Lösung: nur authentifizierte Kunden annehmen. Wäre mir sowieso viel sicherer wegen Belehrung, Rücktritt, Fake-Bestellungen etc. Denen kann man dann eine feste Session-ID zuordnen, die niemals gelöscht wird. Dann muss man aber einen zusätzlichen Login-In PIN vergeben. (@Sven: *pssst* Irgendwann verstehst Du meine Logik auch noch :-))) )

Würd ich ja gern so machen, aber ich bin nicht der, der das entscheidet :/

Conclusion:
Für nicht authentifizierte Kunden ist eine Session "Kanonen auf Spatzen". Da reicht die Methode mit dem HiddenField vollkommen.

Sessions sind halt so einfach und bequem ;) Alles mit Post übermitteln gefällt mir auch nicht so recht (immer diese MessageBox bei Klick auf "zurück"...). Und ausserdem ist mir noch immer nicht klar, wie ich ein hidden-Feld weitergeb an die nächste Seite über einen gewöhnlichen Link (ohne Formularsubmit).

Gruß, Marko

[Tom]

Hello,

Sessions sind halt so einfach und bequem ;) Alles mit Post übermitteln gefällt mir auch nicht so recht (immer diese MessageBox bei Klick auf "zurück"...). Und ausserdem ist mir noch immer nicht klar, wie ich ein hidden-Feld weitergeb an die nächste Seite über einen gewöhnlichen Link (ohne Formularsubmit).

Du willst doch wohl nicht einen shop mit get-Paramtern aufbauen?
Da kann man ja überall unterwegs dazusteigen, es sei denn, Du bekommst die Sessions hin. Dann benötigst Du ja außer der Session-ID (und wenn es nach mir geht, einem weiteren Cookie) nix.

Grüße

Tom