Wie verwalte ich die Sitzung für einen Benutzer, der über die mobile App in PHP angemeldet ist?

Lesezeit: 9 Minuten

Benutzer-Avatar
PHPLover

Ich bin ein PHP-Programmierer von Beruf. Ich habe also keine Ahnung von iOS- und Android-Codierung.

Das Szenario ist, dass es eine Website gibt, die mit einer PHP-Software für soziale Netzwerke mit dem Titel entwickelt wurde “PHFox”.

Jetzt gibt es zwei ähnliche mobile Apps, die die Funktionalität dieser Website genau replizieren. Eine mobile App ist in iOS und eine andere in Android.

Also habe ich eine Reihe von RESTful-APIs geschrieben, bei denen ich die Anfrage von der mobilen App akzeptiere, die Anfrage parse, die Anfrageparameter an die Funktion übergebe, die die gleiche Aufgabe für die Website erledigt, die Antwort von dieser Funktion erhalte und sie umwandle in das JSON-Format umgewandelt und an die mobile App zurückgesendet. Für die iOS- und Android-App verwende ich denselben Satz von REST-API-Dateien.

Wenn sich der Benutzer anmeldet, wird die REST-API für die Anmeldung aufgerufen. Schließlich wird die PHPFox-Funktion zur Authentifizierung aufgerufen, ein Sicherheitstoken wird zusammen mit einigen anderen Benutzerdaten generiert. Bei jedem Login wird der andere Sicherheitstoken von PHPFox generiert. Diese Daten werden in die Sitzung gesetzt. Jetzt wird jedes Mal, wenn ich eine der Funktionen über eine beliebige REST-API-Datei aufrufe, das zum Zeitpunkt der Anmeldung generierte Sicherheitstoken überprüft, und nur bei erfolgreicher Überprüfung des Tokens wird die PHPFox-Funktion aufgerufen. Dieser Verifizierungsprozess wird intern von PHPFox durchgeführt. Das Sicherheitstoken muss also nicht explizit oder implizit an einen REST-API-Aufruf übergeben werden.

Bis jetzt funktioniert alles absolut einwandfrei.

Meine Zweifel beginnen hier. Ich weiß nicht, ob die Sitzung in der iOS/Android-App aufrechterhalten wird. Also, wenn die Sitzung auf dem Server, dh PHPFox, abgelaufen ist, was passiert dann mit der App? Wird es abstürzen? Muss sich der Benutzer erneut anmelden? Wenn der Benutzer die App auf dem Gerät beendet und erneut zur App kommt, muss er/sie den Anmeldevorgang erneut durchführen?

Es gibt zu viele Zweifel in meinem Kopf. Ich komme total durcheinander mit diesen Dingen.

Kann sich bitte jemand mehr auf das Problem konzentrieren, mit dem ich konfrontiert bin? Es wäre wirklich toll, wenn du das ausführlich erklären könntest.

Vielen Dank.

  • Also endlich, wie halten Sie Sitzungen aufrecht, bitte antworten Sie, ich stecke in demselben Problem fest?

    – Sudhanshu Gaur

    14. Januar 2016 um 18:21 Uhr

REST ist naturgemäß sitzungslos. Sie müssen ein Token generieren, wenn sich der Benutzer anmeldet. Sie müssen dieses Token auf Ihrem mobilen Client speichern. Für jede Anfrage müssen Sie ein gültiges Token im Anfrageheader anhängen und auf der Serverseite überprüfen. Wenn das Token abläuft, ist das auf einem Client gespeicherte Token ungültig. Sie müssen sich also wegen der 401-Antwort erneut anmelden. Wenn der Token nicht korrekt ist, müssen Sie 400 antworten. Ich hoffe, dass ich Ihnen behilflich sein kann.

  • Das Token, das Sie beschreiben, klingt genauso wie eine Sitzungs-ID.

    – malhal

    8. August 2015 um 1:34 Uhr

  • Ja, aber sagen Sie mir nur eine Sache, die Sie bei den meisten Android-Apps überprüfen können, dass sie nie wieder nach einer Anmeldung fragen. Legen sie jetzt keine Ablaufzeit fest oder tun sie was?

    – Sudhanshu Gaur

    13. Januar 2016 um 20:32 Uhr

  • Vielleicht hätten sie ein System entwickeln können, das versteht, wenn ein Token abgelaufen ist, und dann ein Token an seine App zurückgeben. Oder das Token läuft nie ab. Ich schlage vor, Sie lesen etwas über Eid.

    – valeriocomo

    15. Januar 2016 um 8:25 Uhr


  • Das ist das Schöne an der Verwendung von Token! Im Gegensatz zu Sitzungen laufen sie niemals implizit ab, es sei denn, man beendet sie explizit.

    – aB9

    22. Juni 2016 um 17:01 Uhr

  • Es ist wahr! Aber es ist eine gute Praxis, dass ein Token nach einer gewissen Zeit abläuft. JSON Web Token ist der Weg!

    – valeriocomo

    23. Juni 2016 um 13:58 Uhr

Benutzer-Avatar
Fawad Masud

Im Gegensatz zu Webbrowsern können iOS- und Android-Apps keine Sitzungen aufrechterhalten. Sobald sich ein Benutzer angemeldet hat (Anmeldeinformationen vom Server überprüft), werden seine Anmeldeinformationen normalerweise auf der Clientseite gespeichert. Dann ruft die App mithilfe von sitzungslosen REST-API-Aufrufen Daten vom Server ab. So wird es meistens in mobilen Anwendungen gemacht.

Wenn Sie jedoch möchten, dass die Serversitzung und die mobile App Hand in Hand gehen (was meiner Meinung nach keine gute Idee ist), ist der Weg so

1) Wenn sich der Benutzer anmeldet, wird serverseitig ein Sicherheitstoken generiert und sowohl server- als auch clientseitig gespeichert.

2) Die mobile App kann mit dem Server kommunizieren, solange das Sicherheitstoken gültig ist.

3) Wenn die Sitzung abläuft, wird das Sicherheitstoken ungültig. Nun muss es zwischen Server und Client eine Verständigung über die Antwort geben, wenn die Sitzung abgelaufen ist. Jetzt muss die mobile App den Benutzer erneut zur Anmeldeseite umleiten. Der Benutzer meldet sich erneut an und kommuniziert dann mit dem Server. Dies sollte jedes Mal geschehen, wenn die Sitzung abgelaufen ist.

  • Danke für deine Antwort, aber ich glaube du hast meinen Punkt nicht ganz verstanden. Wenn sich der Benutzer vom Gerät über die iOS/Android-App anmeldet, wird die Sitzung auf dem Server gestartet, PHPFox generiert ein Sicherheitstoken, das in dieser Sitzung festgelegt wird. Bei jeder weiteren Anfrage von der App wird dieses Sicherheitstoken von PHPFox intern verifiziert, um die Funktionalität zu sichern. Mein Zweifel ist, wenn sich der Benutzer nicht von der App abmeldet und die Sitzung auf dem Server abgelaufen ist, dh die PHPFox-Sitzung wird unterbrochen, was soll ich dann tun? Dafür muss die Sitzung meiner Meinung nach auch auf der App-Seite aufrechterhalten werden.

    – PHPLover

    22. Februar 2015 um 7:08 Uhr

  • Und die Sitzung von der App sollte mit der Sitzung vom Server synchron sein. Nur dann wird das Problem nicht aufgeworfen. Kurz gesagt denke ich, dass beide Sitzungen Hand in Hand arbeiten sollten. Hab ich recht?

    – PHPLover

    22. Februar 2015 um 7:09 Uhr

Wenn Sie Oauth 2 für die Authentifizierung verwenden, ist hier die allgemeine Einrichtung:

  • Der Benutzer meldet sich in der mobilen App an
  • Wenn die Anmeldeinformationen in Ordnung sind, gibt der Server das Zugriffstoken, ein Aktualisierungstoken und die Lebensdauer des Tokens zurück
  • Die mobile App speichert diese Werte + den aktuellen Zeitstempel
  • Auf der Serverseite ist ein Garbage Collector konfiguriert, um abgelaufene Token zu löschen
  • Vor jedem API-Aufruf prüft die mobile App, ob das Token bald abläuft (mit Hilfe der gespeicherten Werte). Wenn das Token bald abläuft, sendet die App das Aktualisierungstoken, das den Server anweist, ein neues Zugriffstoken zu generieren
  • Wenn Sie möchten, dass Benutzer verbunden bleiben, kann die App so konfiguriert werden, dass sie das Zugriffstoken regelmäßig überprüft und ein neues anfordert, wenn es veraltet ist

Hoffe das hilft.

Prost

  • Was nützt ein Refresh-Token, wenn jemand Ihren Token stehlen kann, dann kann er/sie auch Ihren Refresh-Token stehlen?

    – aman verma

    10. Januar 2016 um 18:58 Uhr

  • @amanverma-Aktualisierungstoken können widerrufen werden. Diese werden normalerweise mit kurzlebigen Zugriffstoken wie selbstcodierten Token (JWTs) kombiniert, die nicht manuell widerrufen werden können.

    – georaldc

    16. Juli 2019 um 18:52 Uhr

Ihr Server sollte völlig zustandslos sein, daher sollte keine Sitzung gespeichert werden. Eine REST-API ist praktisch nur eine Datenabstraktionsschicht mit optionaler Sicherheit (durch Token).

Ihre API stellt also einen Authentifizierungsdienst bereit, der mit einem Autorisierungstoken antwortet, das für nachfolgende Anforderungen als Header verwendet wird. Dieses Token sollte eine 1-zu-1-Beziehung mit jedem Benutzer sein und universell eindeutig sein. Es sollte auch eine Ablaufzeit haben. Zu diesem Zeitpunkt antwortet Ihr Server mit einer entsprechenden Fehlerantwort und fordert Ihre App auf, das Token zu aktualisieren, was entweder über ein separates Aktualisierungstokensystem erfolgen kann, oder fordert den Benutzer auf, sich erneut anzumelden, um das Token zu aktualisieren .

Es ist die APP, die den Zustand beibehalten sollte, nicht der Server. Der Server dient lediglich Datenzwecken und sollte sich daher nicht auf eine sitzungsbasierte Authentifizierung verlassen.

Benutzer-Avatar
Alex Sanséau

Eine Sitzung ist “etwas”, das auf dem Server lebt. Es kann sich um ein Objekt handeln, das Details über den Benutzer (z. B. Sitzungs-ID, Benutzername, E-Mail-Adresse …) oder andere Daten speichert, die zur Bearbeitung zukünftiger Anfragen erforderlich sind (z. B. Warenkorbdetails, Lieferadresse …).

Dieses “Etwas” ist normalerweise ein Objekt, das im Speicher, in einer Datenbank oder sogar serialisiert und im Dateisystem gespeichert werden kann (ich glaube, dies ist die Standardeinstellung in PHP).

Wenn Sie also sagen „Ich weiß nicht, ob die Sitzung in der iOS/Android-App aufrechterhalten wird“, fürchte ich, dass das keinen Sinn ergibt. Nur der Server kann Sitzungen aufrechterhalten.

Normalerweise ist das einzige, was der Client (Webbrowser oder mobile App) wissen würde, die Sitzungs-ID (in Form eines Tokens oder einer GUID). Das ist das Einzige, woran sich der Client/die App erinnern muss, und es muss zusammen mit jeder Anfrage an den Server gesendet werden.

Es könnte als Cookie gespeichert und/oder als Anforderungsheader an den Server gesendet werden.

Dann liest der Server die Sitzungs-ID/Token aus den Cookies oder dem Header und ruft die Sitzungsdetails von dem Ort ab, an dem er Sitzungen speichert (Dateisystem, Speicher oder Datenbank). Das passiert hinter den Kulissen, wenn Sie anrufen session_start().

Um mehr über die Sitzungsbehandlung und das Erstellen eines benutzerdefinierten Sitzungshandlers zu erfahren (der in Ihrem Fall möglicherweise erforderlich ist, um ein Token aus den Anforderungsheadern zu erhalten):
http://php.net/manual/en/function.session-start.php

Benutzer-Avatar
Ali A. Jalil

Sie sollten sich keine Sorgen um die Sitzung von der Seite der mobilen Entwicklung machen. In Android verwenden wir SharedPrefrence und NSUserDefaults (Flag, das die Sitzung lokal aufrechterhält).

Benutzer-Avatar
Sanand Sule

Ich habe keine Erfahrung mit PHPFox, aber so sollte ein mobiles Frontend idealerweise mit den Problemen umgehen:

Fall 1: Mobile App spricht aktiv mit Server:

  • Der Zeitüberschreitungsstempel der Sitzung wird immer höher und die Sitzung bleibt am Leben.

Fall 2: Mobile App ohne Serverkommunikation aktiv (z. B. eingehender Anruf, Wechseln zwischen Apps usw.):

  • Die Serversitzung kann möglicherweise eine Zeitüberschreitung aufweisen oder nicht.
  • Wenn das Zeitlimit überschritten wird, schlägt die nächste Abfrage an den Server auth und gibt einen Fehler zurück.
  • Die App verarbeitet diesen Fehler und leitet elegant zum Anmeldebildschirm mit einem Nachrichten-Toast weiter, der den Benutzer auffordert, sich anzumelden. (Dies geschieht in meiner Banking-App)

Fall 3: Der Benutzer beendet die App auf dem Gerät und startet sie neu:

  • Die App sollte das Token entweder in sqllite oder in freigegebenen Einstellungen speichern. (Immer eingeloggte Apps verwenden diesen Ansatz)
  • Beim Neustart kann die App den Server mit dem Presistent-Token abfragen.
  • Wenn die Sitzung aktiv ist, geht die Kommunikation durch und der Benutzer kann fortfahren. Wenn nicht, geht der Benutzer zum Anmeldebildschirm wie in Fall 2.

1282640cookie-checkWie verwalte ich die Sitzung für einen Benutzer, der über die mobile App in PHP angemeldet ist?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy