iOS sendet sporadisch alte Cookies

Der Safari View Controller teilt in iOS 11 und höher keine Cookies mehr mit Safari. Diese Änderung löste die Cookie-Speicher-Korruptionsprobleme, die iOS geplagt hatten. Wir haben dieses Problem seit iOS 11 nicht mehr erlebt.

Hier ist meine Theorie von dem, was passiert ist:

Im Cookie-Lebenszyklus wird der alte Cookie ungültig und durch einen neuen Cookie ersetzt, wenn sich der Status der Benutzerauthentifizierung ändert (login user - & gt; logout user || logout user - & gt; login Benutzer).

Aber warum ist das in der U-Bahn passiert und nicht an anderen Orten?
1. Heutzutage bieten die meisten U-Bahnen kostenloses ungesichertes WiFi, um die schlechte drahtlose Netzwerkverbindung während der U-Bahn zu ergänzen.
2. Es gab einige Berichte über Netzwerkkonnektivitätsprobleme in 10.3 und   Besonders interessant ist dieses , da das Problem location dependent war.
3. Ich denke, die Kombination von (1) und (2) oben hat die App dazu veranlasst, sich erneut auf dem Server zu authentifizieren. Vielleicht könnten Sie die Logs ziehen, um zu prüfen, ob das tatsächlich der Fall ist?

Mögliche Abhilfe?

Vielleicht keine.
Wir können nicht verhindern, dass ein iPhone-Nutzer ein iOS-Upgrade durchführt. Und die meisten schon.
Auch die Sicherheitsbeeinträchtigung, Cookies nach erneuter Authentifizierung nicht zu ändern, ist schlechter.

Update basierend auf dem Kommentar zum 31.05.2017:

Angesichts der Details wie im Kommentar. Wir könnten eine bessere Erklärung haben.

Im Cookie-Lebenszyklus sollte beim Abmelden des Benutzers server-side-invalidation stattfinden Der Arbeitsablauf:
 1. Wenn der Benutzer logout , wird authenticated sessionID aus dem Browser gelöscht.
2. Aber das ist nicht genug. Der Server muss invalidate that sessionID ebenfalls haben. Sonst könnte es zu Sicherheitsbeeinträchtigungen kommen.
3. Es könnte sein, dass der Server in Ihrem Fall nicht ungültig wurde. Es erwartet also immer noch SessionID , was deleted from the browser ist.

Dies ist nur eine mögliche Erklärung. Um genau zu sein, mehr Details Log-Datei-Analyse und mehr Experiment wäre erforderlich. Zum Beispiel, während dieser Zeit, im Server-Log gab es eine erneute Authentifizierung stattgefunden?
Können wir in einer kontrollierten Umgebung testen, wenn server-side-invalidation richtig implementiert wurde?

Meine Erfahrung

Ich verwende auch die Authentifizierung über IDs, die sich bei jeder Anfrage ändern und in Cookies gespeichert werden. Ich kann dieses Verhalten bestätigen und es ist immer noch in iOS 11 (und iOS 11.1 Beta 3) vorhanden. In meinen Protokolldateien kann ich sehen, dass manchmal alte Cookies zufällig in Safari gespeichert werden. Dies geschieht in einer eigenständigen Webanwendung, wenn sie geschlossen und erneut geöffnet wird.

Meine Fallback-Methode

Ich habe eine Fallback-Methode über localStorage erstellt. Eine Anfrage mit einem alten Cookie markiert normalerweise alle Daten in meiner Datenbank als ungültig. Wenn der Benutzeragent auf ein Gerät mit iOS verweist, markiere ich die Daten nicht als ungültig und gebe dem Client einen zweiten Authentifizierungsversuch.

Auf der Client-Seite überprüfe ich localStorage und erstelle neue Cookies mit diesen Daten. Anschließend findet eine neue Authentifizierung statt. Der localStorage wird wie die Cookies bei jeder Anfrage umgeschrieben. Wenn die Authentifizierung erneut fehlschlägt, markiere ich die Daten als ungültig.

SQLite-Datenbank, wenn Sie bereit sind, etwas Sicherheit zu opfern.