Ich schreibe eine hybride Web / PhoneGap Applikation in Flask. Da Cookies in einer PhoneGap-Anwendung grundsätzlich nicht verfügbar sind, habe ich eine benutzerdefinierte Sitzungsoberfläche vollständig implementiert vermeidet Cookies. Es speichert Sitzungsdaten in der Anwendungsdatenbank und übergibt die Sitzungs-ID explizit in den HTTP-Anfrage- und Antworttextstellen.
Ich habe ein GitHub-Repository mit einem reduzierten Testfall erstellt. Es ist immer noch ein großes Projekt, aber die Readme sollte Ihnen helfen, sich schnell zurecht zu finden. Das Repo umfasst sieben Tests, die alle erfolgreich sind, wenn die standardmäßige Cookie-basierte Sitzungsschnittstelle von Flask verwendet wird und alle mit meiner benutzerdefinierten Sitzungsschnittstelle fehlschlagen. Das Hauptproblem scheint zu sein, dass Daten manchmal nicht auf dem Sitzungsobjekt gespeichert werden, aber das ist mysteriös, weil das Sitzungsobjekt von Pythons eingebautem dict erbt, das die Daten nicht spontan vergessen sollte. Außerdem ist das Session-Interface unkompliziert und scheint keine offensichtlichen Fehler zu machen im Vergleich zu Flasks Beispiel Redis Session Snippet .
Um die Sache frustrierender zu machen, scheint die benutzerdefinierte Sitzungsschnittstelle in der tatsächlichen Anwendung korrekt zu funktionieren. Nur die Komponententests sind fehlgeschlagen. Aus diesem Grund ist es jedoch nicht sicher anzunehmen, dass die Sitzungsschnittstelle unter allen Umständen korrekt funktioniert.
Hilfe wird sehr geschätzt.
Bearbeiten: Gist akzeptiert den reduzierten Testfall nicht, da er Verzeichnisse enthält. Ich bewege es jetzt zu einem ausgewachsenen GitHub-Repository. Ich werde diesen Beitrag erneut aktualisieren, wenn Sie fertig sind.
Neue Bearbeitung: hat den reduzierten Testfall in ein passendes GitHub Repo verschoben. Die Readme erwähnt immer noch "this Gist", sorry.
Ihre Probleme meistens hängen davon ab, das Sitzungstoken in Ihren Testanforderungen bereitzustellen. Wenn Sie das Token nicht angeben, ist die Sitzung leer.
Ich gehe davon aus, dass Ihre tatsächliche Anwendung das Sitzungstoken korrekt sendet und somit funktioniert.
Es braucht nicht viel, um die Testfälle korrekt zu durchlaufen.
In Ihrer Sitzungsimplementierung:
%Vor% Dies bedeutet, dass jede Anfrage, die nicht POST (oder PUT ) ist und nicht t gesendet hat
habe eine leere Sitzung.
Während eine cookies-basierte Implementierung immer das Session-Token zur Verfügung hat und kann Sitzungen früherer Anfragen laden.
Hier ist einer Ihrer Beispieltests:
%Vor% Sie haben keinen t -Wert für den Post an /test angegeben. So wird es leer
Sitzung, die keinen captcha-expires -Schlüssel hat und ein KeyError wird ausgelöst.
In Ihrer Sitzungsimplementierung:
%Vor%Also wenn du hast:
%Vor% Es wird keine Sitzung in die Datenbank geschrieben. Für jede weitere Anfrage an
benutzen. Beachten Sie, dass wirklich in die Datenbank geschrieben werden muss, da open_session versucht, bei jeder Anfrage etwas aus der Datenbank zu laden.
Um die meisten dieser Fälle zu beheben, müssen Sie beim Erstellen der Sitzung ein "Token" und für alle Anfragen, die sie verwenden, ein "t" angeben.
Damit würde der Beispieltest, den ich oben verwendet habe, wie folgt enden:
%Vor%... aber Sie verwenden das neue Token nicht, wenn Sie eine weitere Anfrage machen
%Vor% Hier hat der Beitrag zu /reflection/1/reply eine neue erstellt
token und es gespeichert, somit ist der kritische Schlüssel last-reply nicht in der
Sitzung identifiziert durch abcdef . Wenn dies eine Cookies-basierte Sitzung wäre, wäre last-reply für die nächste Anfrage verfügbar.
Um diesen Test zu beheben ... benutze das neue Token
%Vor% Im Test test_bump :
Der Beitrag in /admin/tip/action gibt eine Weiterleitung zurück.
Hier prüfen Sie das Vorhandensein einer Flash-Nachricht. Und Flash-Nachrichten in der Sitzung gespeichert werden.
Bei einer Cookie-basierten Sitzung wird die Sitzungs-ID mit der nachfolgenden umgeleiteten Anforderung erneut gesendet.
Da Ihre Sitzungs-ID als Post-Wert angegeben wird, wird sie nicht erneut gesendet, die Sitzung und die Flash-Nachrichten gehen verloren.
Der Weg, um dies zu beheben, besteht nicht darin, Weiterleitungen zu folgen, sondern die Sitzung anhand der Flash-Methode flask zu überprüfen.
%Vor%Ich habe eine Pull-Anfrage mit den Änderungen gesendet, wie ich oben beschrieben habe. Sie werden feststellen, dass die Tests nun sowohl für die Standard-Flask-Sitzung als auch für Ihre Sitzungsimplementierung gelten.
Tags und Links python session flask customization