Session-ID url vs. cookie

Hallo,
Ruby on Rails benutzt per default für die Übermittlung der Session-ID cookies. Andere Seiten benutzen eine in der URL kodierte Session-ID. Ich bin mir gerade unschlüssig, welches Verfahren ich verwenden soll. Für den Client werde ich jede Menge JavaScript verwenden, von daher könnte ich mir auch ein Verfahren vorstellen, bei dem die Session-ID als globale Variable im Script auf dem Client gespeichert wird und _alle_ weiteren Seitenabrufe via Ajax gehandhabt werden. Mit fehlen jetzt ein bischen die Argumente für und gegen das eine oder andere Verfahren, von daher hier mal die Frage in die Runde ob ihr mir helfen könntet folgende Liste zu vervollständigen.
Session-Id in URL kodiert:
+ es sind keine cookies nötig
- hässliche URLs
- Da die Session-Id in allen Links auf einer Seite auftauchen, darf die Seite nicht über eine Session hinweg nicht gecached werden.
Cookies:
+ Von der Softwareentwicklungsseite 'fast' kein Aufwand
- Schließt Kunden aus, die cookies deaktiviert haben
+ Der Inhalt manch einer Seite ändert sich nicht bei einer geänderten Session-Id
Session-Id in globaler JavaScript Variablen
- Habe ich in Rails keine Unterstützung für
+ Der Inhalt manch einer Seite ändert sich nicht bei einer geänderten Session-Id
mfg und Dank im Voraus,
Todi

Original von Todi42
Session-Id in globaler JavaScript Variablen

-Forward/Back-Button im Browser funktioniert ohne extra Zutun nicht mehr.

Nimm Cookies. Ist schon von der Sicherheit her die bessere Wahl.
Das mit dem Javascript klingt auch interessant, ich frag mich nur, welchen Nutzen das haben soll. Cookie ist gut, relativ sicher (sicherer als in der URL) und wird allgemein unterstützt.
Außerdem: wer ohne Cookie unterwegs ist, ist wahrscheinlich auch ohne Javascript unterwegs.

Hi Toby,

Nimm Cookies. Ist schon von der Sicherheit her die bessere Wahl.
Ich suche ja gerade Argument für und wieder einer Methode. Warum wären cookies Deiner Meinung nach "sicherer"? Ich hatte bis jetzt immer das Gegenteil gehört. Wenn ich cookies in meinem Browser zu lasse, kann ich Webseitenbetreibern unter Umständen viel mehr mitteilen, als ich möchte. Das es da noch einen Unterschied gibt, zwischen der Seite die den cookie setzt und der Seite, die den Cookie abfragt und das man da Einschränkungen konfigurieren kann ...., "Mein Kollege hat erzählt, das die Böse sind". Gleiches Argument auch für JavaScript.

Das mit dem Javascript klingt auch interessant, ich frag mich nur, welchen Nutzen das haben soll.
Es werden keine cookies benötigt, die Session-Id wird bei POSTs via URL übergen. Der Server muß aber nicht in jeden Link die URL rein frickeln.

Cookie ist gut, relativ sicher (sicherer als in der URL) und wird allgemein unterstützt.
Was meinst Du den mit "sicher" bzw. "sicherer"?

Außerdem: wer ohne Cookie unterwegs ist, ist wahrscheinlich auch ohne Javascript unterwegs.
Da magst Du wahrscheinlich recht haben. Ich könnte mir aber Vorstellen, das des eine gewisse Menge gibt, die keine cookies aber JavaScript zuläßt.
Danke für Deine Anmerkungen
Todi

Nun ja, ein Cookie wird normalerweise nicht weitergegeben. Eine URL schon eher und dann hat unter Umständen jemand Fremdes eine Session-ID, die eventuell sogar noch valide ist. Ergo könnte dieser Fremde dann sogar eine Session kidnappen. Ok, man kann sich serverseitig mit IP-Checks sich dagegen absichern, aber jeder Proxy hebelt sowas schon aus.
Cookies können nicht zufällig freigegeben werden, daher hast du da einen effektiven Sicherheitsgewinn.
Außerdem taucht eine URL auch noch in etlichen Logs (Proxy, Firewall) auf, ein Cookie normalerweise nicht.
Ich persönlich habe meinen Browser so eingestellt, das ich jedes Cookie selber akzeptieren muss (ich akzeptiere allerdings generell Session-Cookies). Halte das aber für eine sehr paranoide Einstellung und die meisten Leute, die ich kenne, wissen gar nicht, was ein Cookie ist oder würden es gar ablehnen.
Bei Browsergames bin ich sowieso der Ansicht, das man gewisse Sachen verlangen kann. Was man schlußendlich verlangt, ist die Sache des Proggers. Wenn man also Cookies zwingend benötigt, müssen die paar Leute, die absolut keine Cookies wollen eben draussen bleiben.
Bei deiner JS-Version würde dieser Sicherheitsgewinn wohl auch zutreffen, solange die Daten via POST übertragen werden.
Allerdings halte ich persönlich den Aufwand für die Minderheit, die gar keine Cookies mag, für zu hoch. Musst du selber wissen.

nimm einfach den standard, normalerweise cookie und wenn keine cookies aktiviert sind dann via url

@Toby: Ja, jetzt verstehe ich es ;-) Das ist in der Tat ein Problem. Die Seiten können ja auch lokal auf der Platte gecached sein, dann kommt zumindest jeder, der Zugriff auf den Rechner hat an so eine Session-ID.
Session-Id in URL kodiert:
- Durch Weitergabe von HTML-Seiten, wird die Session-ID implizit/unwissend weiter gegeben.
@HSINC:
Das bedeutet aber mehr Implementierungsaufwand. Später kommt evtl. noch eine Version ohne Java-Script.

Original von Todi42
@HSINC:
Das bedeutet aber mehr Implementierungsaufwand. Später kommt evtl. noch eine Version ohne Java-Script.

Nicht unbedingt. Du kannst dir eine Variable mit Inhalt "sessionid=xyz" machen die du generell an alle URLs anhängst. Sind Cookies aktiviert bleibt die Variable leer und nichts steht in der URL, ansonsten wird automatisch die Sessionid angehängt.
Die Idee mit Javascript würde ich nochmal überdenken. Zum einen musst du dann wirklich jede Interaktion mit dem Server über Javascript regeln, zum anderern kann der Client gar nichts mehr machen wenn mal Javascript nicht funktioniert.

sag doch einfach mal, wie ne SessionID übergabe bei mir normalerweise ausgesehen hat:
JavaScript client, SessionID wird immer als Post Variable übergeben.
Bedeutet: Sie erscheint weder in einem Traffic log noch auf einer History.
Session ID verliert gültigkeit, sobald logout gedrückt. (einfach pro User SessionID die gerade gültig ist cachen).
Vorteile:
- Multiple Logins nicht möglich
- Fenster Schliessen terminiert das ganze endgültig. Hijacking fast nicht mehr möglich
- SessionID wird von 99 % der User nie gesehen
- Clustering ist absolut kein Problem, da PHP Session nicht benutzt wird
- lässt sich extrem einfach durch Laufnummer erweitern, was Hijacking zusätzlcih erschwert.
Nachteile:
- JavaScript client
- Browser Vor / Zurück terminiert session (kann auch vorteil sein; kommt auf Game darauf an)
- keine parallelen Fenster möglich; es seie denn man codiert das. Gleichzeitig auch Vorteil, da man das ganze einfach coden kann und es dann auch wirklcih im Griff hat
Gruss

Klingt ja schön, aber:

da PHP Session nicht benutzt wird

und wiso machst du dann den aufwand mit der Session id, wenn du die Session funcktion von PHP nicht nutzen willst? *denk* OK, man könnte eine eigene session funktionalität (DB) progen, aber wiso?

Multiple Logins nicht möglich

das hat mit der Client seite nichts zu tun. Wenn du das verhindern willst, mussts du auf der Server Ebene was progen.

keine parallelen Fenster möglich

Wenn ich im FF mich einloge, und dann im IE/FF mich auch/nochmal einlogen will und du auf der Server Seite nicht prüfst, kann ich mich soviel mal einlogen wie ich will.

SessionID wird von 99 % der User nie gesehen

Die muss doch im Quelltext(JS varable?) stehen, die dann bei einem request mitgesendet wird. Auch wenn du sie per ajax am anfang hollst, gibt es da ja noch dom und so.

Erzeuge eine GUID, welche nur einen Klick lang gültig ist.
Selbst wenn der User die Seite neu lädt, ist die GUID nicht mehr gültig.

Original von MrMarco
Selbst wenn der User die Seite neu lädt, ist die GUID nicht mehr gültig.

Sowas find ich als Spieler aber extremst nervig

Original von MrMarco
Erzeuge eine GUID, welche nur einen Klick lang gültig ist.
Selbst wenn der User die Seite neu lädt, ist die GUID nicht mehr gültig.

Es gibt eine Menge BG's wo man der Übersicht halber auch mal zwei Fenster offen hat. Z.B. einmal die Sektor bzw. Weltkarte und einmal die Armeenübersicht oder einfach nur ein zusätzliches Browserfenster zum PM-Schreiben...
Mit den Wegwerf-SIDs geht sowas nicht und das ist sau nervig.
Nebenbei: Wer ausser den BND-Mitarbeitern lässt eigentlich alles keine Cookies zu? Ich meine nur, wer so oft im WWW ist um ein Browsergame spielen zu können (und da smuss ja nunmal mind einmal täglich sein), der hat auch Cookies aktiv. Ich will nicht unbedingt sagen, dass Javascript oder gar Applets standardmässig aktiviert sind, aber ich kenne niemanden, der normale Cookies verbietet. Die meisten wissen ja nicht mal, was das überhaupt ist, geschweige denn, wie man die Sicherheitsstufe des Browsers ändert.
Also ich würde die SID immer im Cookie speichern und dem Cookie eine Gültigkeit von einer Stunde zuweisen. Damit ist die Session zwangsläufig auch nach einer Stunde beendet und der User muss sich neu einloggen...

Zu den mehreren Fenstern: Das steht definitiv in meinem Pflichtenheft und das sollte man mit jedem hier vorgestellten Verfahren (auch den vom MrMarco) hin bekommen. Man muß sein Datenmodel halt explizit darauf ausrichten und dann hat ein Spieler halt 0-n sessions. Allerdings muß man dann explizit eine neue Session aufmachen z.B. über einen "neue Sitzung" Knopf, der Serverseitig dann eine Session anlegt und ein neues Fenster öffnet. Cookies könnten da eher hinderlich sein, weil browser für mehrere offene Fenster die gleichen cookies speichern.

Dann kann es sein, dass du für ein un den selben User plötzlich 5 verschiedene Sessions zur gleichen Zeit hast? Irgendwie erscheint mir das auch nicht wirklich sinnvoll...

Original von Störti
Nebenbei: Wer ausser den BND-Mitarbeitern lässt eigentlich alles keine Cookies zu? Ich meine nur, wer so oft im WWW ist um ein Browsergame spielen zu können (und da smuss ja nunmal mind einmal täglich sein), der hat auch Cookies aktiv. Ich will nicht unbedingt sagen, dass Javascript oder gar Applets standardmässig aktiviert sind, aber ich kenne niemanden, der normale Cookies verbietet. Die meisten wissen ja nicht mal, was das überhaupt ist, geschweige denn, wie man die Sicherheitsstufe des Browsers ändert.

Einige öffentliche Computer; da ich nicht in Internetcafes bin, weiß ich es dort nicht. Beispielsweise nervt der Browser in der FH dauernd - "Wollen sie Cookie annehmen - Wollen Sie Cookie annehmen"..
Eigentlich gibt es auch dafür keine Begründung, denn man kann auch diese Rechner a) sicher machen (wieso ist ein Cookie gefährlich, hat schon mal jemand ein Schokoplätzchen mit einer Pumpgun gesehen?) und b) könnte man ja einmal am Tag die Daten löschen, oder beim Browserschließen..

ich will auch Multiple Logins verhindern, und ich habe das so gedacht:
Ich nutze ADODB und die SESSION Verwaltung von ADODB.
In der DB hat es dann extra ein feld, wo ich einen Wert den ich bestimme speichern kann. Da speichere ich die user_id. Falls die Session terminiert wird, kann man noch eine funcktion aufrufen lassen, Gimik ^^.
Ich dachte ich baue alle links folgendermassen um: (ungetestet)

Bauen
TempFensterID ist eine id die von php generiert wurde, die dann in einer javascript varable gespeichert wird.
Wenn jetzt jemand auf einen link Klickt, wird diese id angehängt.
PHP fürft ob diese id da steht und Stimmt. (id ist in session)
wenn jemand rechtsklick macht und neues tab/fenster wählt, müsst der javascript teil dess Links nicht ausgeführt werden? und dann wird die Variable nicht mitgesendet und das Fenster ist dann üngültig.
Falls er ein neues Fenster öffnet und sich ein 2. mal einlogen(1. fenster noch offen) will, dachte ich, ich lösche einfach die alte Session, da ich ja die user_id in der tabelle mit den sessions in einer separaten spalte habe.

Original von Störti
Dann kann es sein, dass du für ein un den selben User plötzlich 5 verschiedene Sessions zur gleichen Zeit hast? Irgendwie erscheint mir das auch nicht wirklich sinnvoll...

Was stört dich konkret daran? In der 1. Session beobachtet der Spieler die Preise für Gammelfleisch an der Warenterminbörse in der 2. ließt er in einem Forum.
Zu den cookies: Cookies können verwendet werden, um das eigene Surfverhalten aus zu spionieren, wenn es einem Server erlaubt wird, cookies zu lesen, die andere Server gesetzt habe. Das läßt sich abstellen, in dem man nur cookies zuläßt, die nur von dem Server gelesen werden können, vom dem sie auch gesetzt wurden. Das bedeutet aber, das man den Unterschied erst einmal kennen muß.

Original von Todi42
Zu den mehreren Fenstern: Das steht definitiv in meinem Pflichtenheft und das sollte man mit jedem hier vorgestellten Verfahren (auch den vom MrMarco) hin bekommen. Man muß sein Datenmodel halt explizit darauf ausrichten und dann hat ein Spieler halt 0-n sessions. Allerdings muß man dann explizit eine neue Session aufmachen z.B. über einen "neue Sitzung" Knopf, der Serverseitig dann eine Session anlegt und ein neues Fenster öffnet. Cookies könnten da eher hinderlich sein, weil browser für mehrere offene Fenster die gleichen cookies speichern.

Du willst dein serverseitiges Modell darauf ausrichten, dass ein User mehrere Browserfenster offen haben kann? Das eine hat mit dem anderen doch gar nichts zu tun. Aus welchem Fenster ein Request an deinen Server kommt interessiert den gar nicht bzw. macht aus Serversicht keinen Unterschied ...

Original von Todi42
Was stört dich konkret daran? In der 1. Session beobachtet der Spieler die Preise für Gammelfleisch an der Warenterminbörse in der 2. ließt er in einem Forum.
Zu den cookies: Cookies können verwendet werden, um das eigene Surfverhalten aus zu spionieren, wenn es einem Server erlaubt wird, cookies zu lesen, die andere Server gesetzt habe. Das läßt sich abstellen, in dem man nur cookies zuläßt, die nur von dem Server gelesen werden können, vom dem sie auch gesetzt wurden. Das bedeutet aber, das man den Unterschied erst einmal kennen muß.

Ich finde, dass das einfachz uneffizient ist, für einen User mehrere gleichzeitige Sessions zu haben. Die paar KB stören den Server zwar nicht im geringsten, aber es geht mir dabei mehr ums Prinzip, dass pro User eine Session reicht.
Dass Cookies böse sein können von wegen Polizeistaat und Big Brother ist mir klar, aber ich gehe nunmal davon aus, dass Cookies bei allen (ok, 99.9%) zugelassen werden, die ein Browsergame spielen und wegen diesem Bruchteil, der dann keine Cookies zulässt, eine in meinen Augen uneffiziente Lösung zu entwickeln ist ebenfalls uneffizient...

Original von exe
Du willst dein serverseitiges Modell darauf ausrichten, dass ein User mehrere Browserfenster offen haben kann? Das eine hat mit dem anderen doch gar nichts zu tun. Aus welchem Fenster ein Request an deinen Server kommt interessiert den gar nicht bzw. macht aus Serversicht keinen Unterschied ...

Die Sessions sind ja letztendlich dazu da, einen Zustand einem Spieler zuzuordnen, um aus diesem Zustand z.B. einige Parameter für Server-seitige Funktionen zu entnehmen. Im einfachsten Fall ist die Session-ID eine Kennung, die den Benutzer eindeutig identifiziert, ob eingeloggt ist oder nicht spielt eigentlich keine Rolle. Dann kann man die Session erweitern und noch mehr Kontext der Sitzung des Anwenders speichern. Z.b. kann man dort speicher, was für Filter der Spieler in einem Suchdialog gewählt hatte und dies beim nächsten mal als Grundeinstellung vorgeben. Das ganze kann man prinzipiel auch in URLS kodieren, kommt aber schnell an seine Grenzen.
Neben der Identifizierung des Spielers kann ich die Session-Daten auch verwenden, um einen Kontext zu speichern. Angenommen ich habe eine Applikation, in der häufig zwischen zwei komplexeren Formularen gewechselt wird. In beiden Formularen meuchte ich das sehen, was ich dort bei letzten mal eingegeben habe. Jetzt gibt es zwei (wahrscheinlich auch mehr) Möglichkeiten das zu machen. Entweder merkt sich der Server in den Session-Daten, was der Benutzer da beim letzten mal eingeben hat, oder aber ich kodieren in den POST-Daten des einen Formulars immer noch zusätzlich die Eingaben der anderen Seite. Im Prinzip lege ich die gesammten Session-Daten damit immer irgend wo im HTML-Text ab und das Verfahren hat dann einfach irgend wo seine Grenzen.
Also Speicher ich den Kontext für eine Session / Sitzung auf dem Server. Möchte ich jetzt zwei mal zwischen diesen Formularen wechseln und mach mir ein neues Fenster für eine zweite Session auf, so müssen dann auch auf dem Server die Session Daten doppelt gehalten werden, wenn ich nicht den Effekt bekommen möchte, das ich in dem einen Fenster Eingaben mache und die später dann als Vorbelegung in dem anderen Fenster sehe.

Es ist doch recht einfach: Die meisten Games haben Sicherheitsprobleme beim Einsatz paralleler Fenster.
-> Deshalb: Wieso nicht einfach unterbinden???
Respektive eine JavaScript lösung für Session Handling nehmen? Der Sinn dahinter ist nämlich auch, dass du problemlos (wenn du JS verwendest) die Requests über ein "Master" Fenster laufen lassen kannst... nur Präsentation in anderem Fenster machst.
Fazit: Aus Sicht Server ist es genau 1 Fenster, damit ist Sicherheit sicher kein Problem mehr.
Gruss

Todi42: wenn jemand im zweiten Fenster das gleiche Formular bearbeitet wie im ersten Fenster ist es nur recht und billig die Autovervollständigung fensterübergreifend arbeiten zu lassen.
schokofreak: ob du die Requests über ein "Masterfenster" oder ein beliebiges machst ist aus serversicht kein Unterschied. Der Server kriegt nur einen HTTP-Request mit ein paar angehängten Daten. Welches Fenster den Request geschickt hat oder in welchem die Antwort angezeigt wird weiss der Server nicht und sollte ihn auch gar nicht interessieren ...
Der Server soll anfragen entgegennehmen und HTML/JS/Grafiken zurückschicken und sich nicht um die Fensteranordnung auf dem Client kümmern ...

Original von schokofreak
Es ist doch recht einfach: Die meisten Games haben Sicherheitsprobleme beim Einsatz paralleler Fenster.

Wirklich?
Kannst du das erklären?
Ich denke eher, die meisten Games haben Usability-Probleme bei nur einem Fenster

Original von exe
schokofreak: ob du die Requests über ein "Masterfenster" oder ein beliebiges machst ist aus serversicht kein Unterschied. Der Server kriegt nur einen HTTP-Request mit ein paar angehängten Daten. Welches Fenster den Request geschickt hat oder in welchem die Antwort angezeigt wird weiss der Server nicht und sollte ihn auch gar nicht interessieren ...

Falsch: Das Master Fenster sorgt dafür, dass immer nur ein Request abgearbeitet wird -> kann so eingesetzt werden dass parallelität nicht mehr möglich ist.
des weiteren hat ein Master-Fenster enorme Vorteile im Bezug auf Caching / Reduktion der Serverlast.

Parallelität stellt die PHP-Session ab.
Solange die Session durch ein Script offen ist (in der Regel bis zur Abarbeitung des scripts), wird kein anderes Script mit der gleichen Session gestartet, es wartet bis die andere Session geschlossen ist.
Gut zu beobachten bei Frames.
[quote=php]
void session_write_close ( void )
Beendet die aktuelle Session und speichert die Session-Daten.
Session-Daten werden normalerweise nach Beenden eines Scripts gespeichert, ohne dass session_write_close() aufgerufen werden muss, aber da Session-Daten gesperrt werden, um gleichzeitiges Schreiben zu verhindern, kann jeweils immer nur ein Script auf eine Session einwirken. Bei der Verwendung von Framesets zusammen mit Sessions werden Sie merken, dass wegen dieser Sperrung ein Frame nach dem anderen geladen wird. Sie können die Zeit zum Laden aller Frames reduzieren, indem Sie die Session beenden, sobald alle Änderungen an den Session-Variablen durchgeführt sind.
Da ich sowieso bei jeder Aktion den Session-Zähler hochsetze, hab ich damit kein Problem (auch schon getestet).

Original von Blabbo

Original von schokofreak
Es ist doch recht einfach: Die meisten Games haben Sicherheitsprobleme beim Einsatz paralleler Fenster.

Wirklich?
Kannst du das erklären?
Viele Spiele testen die Parameter nciht gründlich genug, nehmen versteckte Felder zum Übertragen von Daten zwischen Seiten etc. pp. Darauf wollte er hinaus denke ich mal...

was spricht eigentlich dagegen, per session-set-save-handler und geeigneten Funktionen aus dem gleichen Bereich das SID-uebergeben von PHP selbst zu nutzen?
MFG

Original von schokofreak
Es ist doch recht einfach: Die meisten Games haben Sicherheitsprobleme beim Einsatz paralleler Fenster.
-> Deshalb: Wieso nicht einfach unterbinden???

Wieso nicht einfach die Sicherheitsprobleme lösen. Scheint mir erst einmal offensichtlicher ;-)

Original von schokofreak

Fazit: Aus Sicht Server ist es genau 1 Fenster, damit ist Sicherheit sicher kein Problem mehr.
Und auch keine Kunden mehr. Daraus folgt: Keine Kunden -> Keine Sicherheitsprobleme.

Original von exe

wenn jemand im zweiten Fenster das gleiche Formular bearbeitet wie im ersten Fenster ist es nur recht und billig die Autovervollständigung fensterübergreifend arbeiten zu lassen.
Wenn ich es aber anders herum haben möchte? In dem einen Fenster möchte ich die USS Enterprice befehligen, in dem anderen Fenster die MS Störtebecker.

Original von exe

Der Server soll anfragen entgegennehmen und HTML/JS/Grafiken zurückschicken und sich nicht um die Fensteranordnung auf dem Client kümmern ...
Macht er doch gar nicht. Er bekommt eine Anfrage, entnimmt ihr eine Session-ID, schlägt die Daten der Session nach und beantwortet jetzt mit diesem vollen Kontext die Anfrage. Es stört den Server halt nicht, das der gleiche Spieler mehrere Sessions haben kann.