String Dokumentenübergrifend durchreichen

[Elma]

Hi.

Ich bin ja auf local storage und indexedDB ausgewichen, weil cookies derzeit ja relativ umstritten sind.
Wenn Cookies im Browser deaktiviert sind, funktioniert aber oft auch Local Storage und indexedDB nicht. In vielen aktuellen Browsern ist das in den Einstellungen ein gemeinsamer Punkt. (Datenspeicherung zulassen) Eine differenzierte Einstellung ist zwar über die Config (z.B. about:config) möglich, aber dahin verirrt sich kaum ein "Otto-Normal-User".
Daher ist es oft so, dass entweder alles oder nichts geht.

Wenn man nun eine singe site Seite erstellt, kann man auch einfach alles in einer Variablen halten solange die Seite offen ist.

Aber was nun, wenn man einen String (Das Session Token) innerhalb der Seite zwischen verschiedenen Dokumenten durchreichen will, welche Möglichkeiten habe ich auf JS Ebene dazu?
Klar kann man den Weg gehen, wie es auch bei PHP gemacht wird, und alle Links umschreiben.

Könnte man nicht auch den Browsercache nutzen? Sprich, ich rufe per script Tag einmal zu beginn "token.js" vom Server mit einem Random URL Parameter ab. Diese Datei wird serverseitig dynamisch erzeugt und enthält eine Variable mit dem Token. Sie wird vom Browser gecached, und dann steht in jedem Dokument wirklich das Token zur Verfügung?

Oder gibt es noch andere Möglichkeiten? Vielleicht über die Browser History API?

 

[tsseh]

Ich bin ja auf local storage und indexedDB ausgewichen, weil cookies derzeit ja relativ umstritten sind.

du willst das session handling selbst übernehmen? ist das ne gute idee?

Daher ist es oft so, dass entweder alles oder nichts geht.

da würde ich mich auf den standpunkt stellen, keine cookies, keine session

Aber was nun, wenn man einen String (Das Session Token) innerhalb der Seite zwischen verschiedenen Dokumenten durchreichen will, welche Möglichkeiten habe ich auf JS Ebene dazu?
Klar kann man den Weg gehen, wie es auch bei PHP gemacht wird, und alle Links umschreiben.

würde ich so machen, wenn du das schon selbst in die hand nehmen möchtest (bzw. php machen lassen)

Könnte man nicht auch den Browsercache nutzen? Sprich, ich rufe per script Tag einmal zu beginn "token.js" vom Server mit einem Random URL Parameter ab. Diese Datei wird serverseitig dynamisch erzeugt und enthält eine Variable mit dem Token. Sie wird vom Browser gecached, und dann steht in jedem Dokument wirklich das Token zur Verfügung?

entweder es wird gecached, oder wieder vom server gelesen, ist doch beides ok

 

[Elma]

Hi.
Ja ich will das Session Handling selbst übernehmen. Ich arbeite aber auch nicht mit PHP sondern mit node.js. Und dort auch nur mit dem HTTP Modul und ohne Middleware wie z.B. Express.
Das heißt, ich mache das "Dokumentenrouting", also Umsetzung von URLs auf Dateinamen selbst, und auch die Sessionverwaltung. Damit ich größtmöglich Einfluss darauf nehmen kann.
Das betrifft aber nur den Kern. Bei dem "Drumherum" sieht es anders aus.

Allerdings muss ich einen User während der Sitzung wieder erkennen, auch wenn Cookies und damit local storage deaktiviert sind und ein anderes Dokument aufgerufen wird, wie z.B. der Bilduploader.
Und der darf nicht per Direktlink nutzbar sein, sondern nur wenn man über die Startseite kam.

Vielleicht kann ich es auch über http auth machen. Diese Daten werden von den Browsern auch gecached.

 

[mikdoe]

Ich bin ja auf local storage und indexedDB ausgewichen, weil cookies derzeit ja relativ umstritten sind.

ich kann mir beim besten willen nicht vorstellen, dass ein gericht das unterscheiden würde. daten auf dem client speichern ist es alles und darauf muss man per single-opt-in hinweisen.

 

[Elma]

Hi.

Ein Hinweis muss natürlich angebracht werden.
Einige machen den Hinweis aber auch nur so, dass sie schreiben: "durch die Nutzung der Seite erklären sie sich mit Cookies einverstanden. Wenn sie das nicht möchten, haben sie die Möglichkeit, Cookies in ihren Browsereinstellungen zu deaktivieren".

Ich habs bei mir so vorgesehen, dass alle frei abrufbaren Bereiche ohne Cookies o.ä auskommen sollen.
Einerseits weil es ja deaktiviert sein könnte. Andererseits könnte man dann auch noch einfach ein Flag mit einbauen, welches beim Opt-Out auf False gesetzt wird und dann im Code genauso wie ein nicht verfügbar ausgewertet wird.

Allerdings wollte ich alternativ ein Token von Dokument zu Dokument durchreichen, in einer Datenschutzrechtlich erlaubten Form.
Anders kann ich einen geschlossenen Ablauf kaum realisieren da sonst die Seite jedes mal auf den Grundzustand zurück gehen würde.

Lediglich bei einer Single Page Site würde es gehen, da man dann den Zustand der Seite irgendwo im DOM Baum bzw Javascript Variablen hinterlegen kann.
Dann müsste man aber immer alles über AJAX nachladen und anzeigen. Selbst irgendwelche sekundären Seiten wie z.B. Benutzeranleitung. Oder man muss diese Sachen dann in einem neuen Fenster öffnen. Dann bleibt im Hauptfenster ja alles erhalten.

 

[tsseh]

Ein Hinweis muss natürlich angebracht werden.
Einige machen den Hinweis aber auch nur so, dass sie schreiben: "durch die Nutzung der Seite erklären sie sich mit Cookies einverstanden. Wenn sie das nicht möchten, haben sie die Möglichkeit, Cookies in ihren Browsereinstellungen zu deaktivieren".

das darfst du aber vermutlich gerade nicht tun, weil selbst wenn cookies deaktiviert werden, du den nutzer trotzdem identifiezieren möchtest.
oder ist das rein auf cookies beschränkt?
edit: den 2. satz meine ich, den 1. musst du auch anzeigen.

Ich habs bei mir so vorgesehen, dass alle frei abrufbaren Bereiche ohne Cookies o.ä auskommen sollen.

"auskommen können"

Lediglich bei einer Single Page Site würde es gehen, da man dann den Zustand der Seite irgendwo im DOM Baum bzw Javascript Variablen hinterlegen kann.

das token muss doch sowieso bei jedem zugriff auf den server mitgesendet werden. dann kannst, nein musst du doch der neuen seite gleich das neue token mitgeben.

 

[mikdoe]

du den nutzer trotzdem identifiezieren möchtest

hat er recht, denn es geht ja um die erfassung und speicherung von daten des client nicht darum, ob man auf dem client etwas speichert.

 

[Elma]

Ob die Cookie Richtlinie nur für Cookies gilt, weiß ich nicht. Jedenfalls ist Local Storage auch weg wenn der User Cookies im Browser deaktiviert hat. (Sofern es nicht über die Browser Config separat eingestellt wird)

Um das Token zu übertragen könnte man nun den PHP-Weg gehen. Alle Links werden mit einer Session ID ausgestattet und so an die nächste Seite durchgereicht.
Wenn die Seite ohnehin JavaScript erfordert, könnte man das Anhängen auch auf Nutzerseite machen.
Auf jeden Fall möchte ich aber, dass weder in der Adressleiste eine User ID sichtbar ist, noch bei Rechtsklick-"Link kopieren" eine Session ID mitkopiert wird damit sie nicht so leicht von Otto Normal User weiter gegeben werden kann.
Wenn die ID weiter gegeben wird, könnte nämlich problemlos die Startseite umgangen werden da jemand anders ja den Status damit übernimmt.

Würde eigentlich die History API auch unter die "Cookie Richtlinie" fallen?
In der History API kann man den Seitenzustand per JavaScript nämlich ebenfalls speichern.

 

[tsseh]

Alle Links werden mit einer Session ID ausgestattet und so an die nächste Seite durchgereicht.
Wenn die Seite ohnehin JavaScript erfordert, könnte man das Anhängen auch auf Nutzerseite machen.

wozu auf clientseite? du brauchst das ja nur auf serverseite. sprich, wenn du die nächste seite vom server lädst, musst du sowieso das token mitgeben um den nutzer zu authentifizieren. das neue token gibst du dann der neuen seite wieder mit.

Auf jeden Fall möchte ich aber, dass weder in der Adressleiste eine User ID sichtbar ist, noch bei Rechtsklick-"Link kopieren" eine Session ID mitkopiert wird damit sie nicht so leicht von Otto Normal User weiter gegeben werden kann.

otto normaluser darf mit der id überhaupt nichts anfangen können.

Wenn die ID weiter gegeben wird, könnte nämlich problemlos die Startseite umgangen werden da jemand anders ja den Status damit übernimmt.

nein, um gottes willen, die id/das token ändert sich mit jedem aufruf des servers.

Würde eigentlich die History API auch unter die "Cookie Richtlinie" fallen?

mhh, probiers mal aus

In der History API kann man den Seitenzustand per JavaScript nämlich ebenfalls speichern.

was hast du aber davon?

 

[Elma]

wozu auf clientseite? du brauchst das ja nur auf serverseite. sprich, wenn du die nächste seite vom server lädst, musst du sowieso das token mitgeben um den nutzer zu authentifizieren. das neue token gibst du dann der neuen seite wieder mit.

otto normaluser darf mit der id überhaupt nichts anfangen können.

nein, um gottes willen, die id/das token ändert sich mit jedem aufruf des servers.

Also am Besten mit jeder Anfrage ein neues Token / Session ID erstellen, welches nur für den nächsten Aufruf gültig ist?
Aber wie verhindert man, dass jemand anders die Session "Übernehmen" könnte, wenn er an das Token gelangen würde?
Man könnte noch den User Agent und IP abfragen, dann dürfte das sich aber während der Sitzung nicht ändern.

Mir gehts darum, dass man keine Inhalte sehen kann, wenn man nicht über die Startseite bzw die vorgesehenen Einstiegswege geht.
Wenn kein Token da ist, soll man auf die Einstiegsseite zurück geworfen werden, statt z.B. das Bild angezeigt zu bekommen.

Man braucht zwar keinen festen Account, aber mindestens einen Gast Login, der so lange gültig ist, bis das Browserfenster geschlossen wird.
Der Gast Login erfolgt, in dem man einen beliebigen Nickname eingibt und das Passwort-Feld leer lässt.

Davon ausgenommen sind nur die statischen Inhalte und von mir erstellte, "redaktionelle" Seiten.


Ich möchte eben vermeiden, dass User die Möglichkeit haben, bei mir Bilder zu posten, und diese dann irgendwo anders per direkt-Link nutzen könnten oder dass Bilder gebookmarkt werden können o.ä. Sie sollen nur sichtbar sein, wenn man die Seite auch gerade in dem Moment aktiv nutzt.


Ich habe mal ein paar Tests gemacht:
Die History API ist auch mit deaktivierten Cookies verfügbar. man kann ein Zustandsobjekt speichern, so dass bei der Nutzung von vor/zurück Buttons oder Verlauf im Browser wieder der jeweilige Zustand hergestellt werden kann, also die Session wieder aufgenommen werden kann. Funktioniert aber nur solange der Tab noch nicht geschlossen wurde.

Aber das würde reichen, um bei einem User mit deaktivierten Cookies/Local Storage, der eine Statische Seite wie z.B. FAQ aufgerufen hat, die Sitzung anschließend wieder auf zu nehmen.

 

[tsseh]

Also am Besten mit jeder Anfrage ein neues Token / Session ID erstellen, welches nur für den nächsten Aufruf gültig ist?

mindestens aber eine kurze zeitspanne nach der das token ungültig wird.

Aber wie verhindert man, dass jemand anders die Session "Übernehmen" könnte, wenn er an das Token gelangen würde?

https

Aber das würde reichen, um bei einem User mit deaktivierten Cookies/Local Storage, der eine Statische Seite wie z.B. FAQ aufgerufen hat, die Sitzung anschließend wieder auf zu nehmen.

ich würde für statische seiten genau so verfahren wie für gesicherte

 

[Elma]

mindestens aber eine kurze zeitspanne nach der das token ungültig wird.

Hi.
Was wäre eine kurze Zeitspanne? 1 Minute?
Und wie kommt man an ein neues Token, wenn der User nicht aktiv ist? Würdest du das dann per AJAX machen?

Theoretisch müsste man ja HTTPS verpflichtend einsetzen, um die Authentifizierung sicher zu machen und Session Diebstahl zu unterbinden.
Sonst kann ja jeder per Netzwerkmonitor Logindaten oder Session Tokens "Übernehmen".

Aber normales http für den internen Bereich komplett sperren? Würde das denn keine Nachteile mit sich bringen?

Was die statischen Seiten betrifft:
Klar, man kann den Token Mechanismus auch da einbauen.
Aber dann nur so, dass das Token nur durchgereicht bzw immer wieder erneuert wird, aber auch ohne Token oder gar JS angezeigt werden können.


Bei den Bildern im internen Bereich habe ich folgende Idee:
Ich lade die Bilder ausschließlich über XHR und setze dabei einen X-Request-ID Header. Außerdem wird der Referrer überprüft. Nur wenn beides vorhanden ist, und der Referrer stimmt, wird das Bild ausgeliefert. Damit sollten Deep Links und Bookmarking/Direktzugriffe unterbunden sein. Trotzdem muss ich die Bilder nicht durch mein node.js Script schicken sondern kann sie direkt über nginx ausliefern.

 

[tsseh]

Was wäre eine kurze Zeitspanne? 1 Minute?

irgendwas zw. 5 und 15

Und wie kommt man an ein neues Token, wenn der User nicht aktiv ist?

wenn er in der zeit nicht aktiv war, muss er sich neu einloggen

Würdest du das dann per AJAX machen?

der user muss innerhalb der zeitspanne wieder eine neue seite vom server abgerufen haben, dann lässt du die zeit wieder bei 0 los laufen.

Aber dann nur so, dass das Token nur durchgereicht bzw immer wieder erneuert wird, aber auch ohne Token oder gar JS angezeigt werden können.

ja