FastCGI-Sessions und ihre Laufzeit



  • 'hoi,

    angenommen, ich möchte eine Webanwendung schreiben, die via FastCGI an einen nginx angebunden ist. Diese Webanwendung soll sich für die Dauer eines Besuchs (also vom ersten bis zum letzten Klick) für jeden Besucher eine bestimmte Menge an Daten merken, nach dem Schließen des Browsers können diese Daten sozusagen weggeworfen werden. Cookies erscheinen mir daher nicht unbedingt als sinnvoll.

    Kann ich über FastCGI (z.B. C++) so was Ähnliches wie PHPs $_SESSION verwenden? Wenn ja: wie?


  • Mod

    Sessions funktionieren so, dass der Client per Cookie oder URL seine Session ID der Webseite meldet und die Webseite Anhand der Session ID die Daten assoziieren kann.

    PHP $_SESSION legt zB eine Datei mit der Session ID als Name an und schreibt da alle Session Daten rein. Eine Datenbank wäre natürlich schneller - oder wenn es C++ ist kannst du es ja auch einfach Inmemory vorhalten.



  • Wieder was gelernt, danke. 👍

    Das heißt, zur Simulation von $_SESSION müsste ich jedem Besucher einen Cookie (Lebensdauer: bis die Seite verlassen/der Browser geschlossen wird, also ohne Expires) mit einer Session-ID zuweisen und dann eine sessions.txt ("in memory" könnte bei ausreichend Besucheransturm etwas anstrengend werden, ich bin mir auch hinsichtlich der DDoS-Sicherheit da nicht ganz sicher) mit sessionid;var1;var2;var3... anlegen?

    URL-Parameter haben den Nachteil, dass man beim Weitergeben der URL versehentlich seine Session übernehmen lassen kann. Wäre mir nicht recht. Außer, ich halte zusätzlich noch IPs fest. 😕


  • Mod

    Pulk schrieb:

    Das heißt, zur Simulation von $_SESSION müsste ich jedem Besucher einen Cookie (Lebensdauer: bis die Seite verlassen/der Browser geschlossen wird, also ohne Expires) mit einer Session-ID zuweisen und dann eine sessions.txt ("in memory" könnte bei ausreichend Besucheransturm etwas anstrengend werden, ich bin mir auch hinsichtlich der DDoS-Sicherheit da nicht ganz sicher) mit sessionid;var1;var2;var3... anlegen?

    Du kannst ruhig ein Expire von 30 Minuten oder so setzen, und dann eben bei jedem Aufruf einer Seite das Cookie neu setzen.

    Unabhängig vom Cookie sollte deine Session aber auch ein eigenes Timeout mit sich führen - einfach damit du alte Sessions sauber löschen kannst. 30 Minuten (ohne Seiten aufruf) ist oft ein guter Wert.

    Und ja, thereotisch kann man DOS Angriffe mit vielen Session IDs machen - hier kannst du aber auch einfach eine maximale Anzahl an Sessions erlauben und dann die älteste killen.

    Unabhängig von alle dem: sobald der User eine wichtige Aktion tätigt (zB Daten löschen, etc) dann solltest du sowieso immer nochmal das Passwort anfordern. Weiters kann es auch Sinn machen an gewissen Stellen eine neue Session ID zu generieren. zB wenn der User das Admin Panel öffnet schickst du ihm eine neue Session ID. So dass du den Effekt von "leaks" reduzieren kannst.

    URL-Parameter haben den Nachteil, dass man beim Weitergeben der URL versehentlich seine Session übernehmen lassen kann. Wäre mir nicht recht. Außer, ich halte zusätzlich noch IPs fest. 😕

    Ja, Session ID in der URL kann leicht "leaken". Aber IP checken ist auch fragwürdig - zB ein Mobil Telefon wechselt oft die IP (es logt sich in jedes WLAN ein und wechselt Sendemasten, gerade wenn man unterwegs ist). IP ist also keine gute Metrik.

    Du kannst Sachen verwenden die sich nicht ändern, zB den User Agent. Aber meistens nimmt man Cookies, weils simpler ist und weniger Fehleranfällig.



  • Das mit dem Timeout ist eine gute Idee, und dann bei jedem Seitenladen den Timer zurücksetzen... danke. 👍


Anmelden zum Antworten