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

Question

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

Das Szenario ist dort ist eine Website, die eine Social Networking PHP-Software mit dem Titel "PHPFox" entwickelt.

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

Also habe ich eine Reihe von RESTful APIs geschrieben, wo ich die Anfrage von mobilen App akzeptiere, die Anfrage analysieren, die Anfrage Parameter an die Funktion übergeben, die den gleichen Job für die Website tut, erhalten die Antwort von diesem Funktion, konvertieren Sie es in JSON-Format und schickte es zurück zur mobilen App. Für die iOS- und Android-App verwende ich denselben Satz von REST-API-Dateien.

Wenn sich ein Benutzer anmeldet, wird die REST-API für die Anmeldung aufgerufen. Schließlich wird die PHPFox-Funktion für die Authentifizierung aufgerufen, ein Sicherheitstoken wird zusammen mit einigen anderen Benutzerdaten generiert. Bei jedem Login wird das unterschiedliche Sicherheitstoken von PHPFox generiert. Diese Daten werden in die Sitzung eingegeben. Jedes Mal, wenn ich eine der Funktionen über eine REST-API-Datei aufruft, wird das zum Zeitpunkt der Anmeldung generierte Sicherheitstoken überprüft und erst nach erfolgreicher Überprüfung des Tokens wird die PHPFox-Funktion aufgerufen. Dieser Verifizierungsprozess wird intern von PHPFox durchgeführt. Es ist also nicht erforderlich, das Sicherheitstoken explizit oder implizit an einen REST-API-Aufruf zu übergeben.

Bis jetzt funktioniert alles einwandfrei.

Meine Zweifel beginnt von hier. Ich weiß nicht, ob die Sitzung in der iOS/Android App gepflegt wird. Also, wenn Session auf Server, d. H. PHPFox Zeit abgelaufen ist, was wird dann mit der App passieren? Wird es abstürzen? Muss sich der Benutzer erneut anmelden? Wenn der Nutzer 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 bin total verwirrt mit diesen Dingen.

Kann jemand bitte mehr Fokus auf das Problem setzen, das ich gegenüberstelle? Es wäre wirklich toll, wenn Sie das im Detail erklären könnten.

Danke.

Answer 1

Im Gegensatz zu Webbrowsern können iOS- und Android-Apps keine Sitzungen verwalten. Sobald sich ein Benutzer angemeldet hat (Anmeldeinformationen wurden vom Server bestätigt), werden seine Anmeldeinformationen normalerweise auf der Clientseite gespeichert. Dann ruft die App Daten vom Server ab, die Session-lose REST-API-Aufrufe verwenden. So wird es meistens in mobilen Anwendungen gemacht.

Wenn Sie jedoch die Server-Sitzung und mobile app Hand in Hand gehen wollen (was ich glaube nicht eine gute Idee ist), ist die Art und Weise

1) Wenn sich der Benutzer anmeldet, ein Sicherheits-Token wird auf der Serverseite generiert und sowohl auf der Server- als auch auf der Clientseite 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. Jetzt muss zwischen Server und Client über die Antwort nach Ablauf der Sitzung ein Verständnis bestehen. Jetzt muss die mobile App den Benutzer erneut zur Anmeldeseite umleiten. Der Benutzer wird sich erneut anmelden und dann mit dem Server kommunizieren. Dies sollte jedes Mal passieren, wenn die Sitzung abgelaufen ist.

Answer 2

Wenn Ihr Oauth 2 für athentication verwenden, hier ist die gemeinsame Einrichtung:

• Benutzer anmeldet mobile app
• in Wenn die Anmeldeinformationen sind ok, der Server die Zugriffstoken zurückgibt, eine Aktualisierungs-Token und das Token der Lebensdauer
• die mobilen App speichern diese Werte + aktuelle Zeitstempel
• auf der Seite des Servers, ein Garbage Collector konfiguriert ist abgelaufen Token löschen
• Vor der Herstellung api Rufen Sie an, die mobile App prüft, ob das Token bald abläuft (mit Hilfe der gespeicherten Werte). Wenn das Token kurz vor dem Ablauf steht, 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 alt ist

Hoffe, dass dies hilft.

Prost

Answer 3

Ich habe keine Erfahrung mit phpFox arbeiten, aber das ist, wie ein mobiles Frontend in idealer Weise die Themen behandeln soll:

Fall 1: Mobil App aktiv im Gespräch mit Server:

• Der Sitzungs-Timeout-Stempel staut weiter und die Sitzung bleibt am Leben.

Fall 2: Mobil App aktiv ohne Server-Kommunikation (z eingehender Anruf, Bewegen zwischen Anwendungen usw.):

• Server-Sitzung kann oder nicht Timeout.
• Wenn das Zeitlimit überschritten wird, wird bei der nächsten Abfrage an den Server die Authentifizierung fehlschlagen und ein Fehler zurückgegeben.
• Die App verbraucht diesen Fehler und leitet den Anmeldebildschirm mit einer Nachricht, die den Benutzer zur Anmeldung auffordert, automatisch um. (Dies geschieht in meinem Banking App)

Fall 3: User töten die App auf dem Gerät und relauncht es:

• Die App das Token entweder in SQLLite oder gemeinsame Präferenzen gespeichert werden sollen. (Immer eingeloggte Apps verwenden diese Methode.)
• Nach dem Neustart kann die App den Server mit dem entsprechenden Token abfragen.
• Wenn die Sitzung aktiv ist, wird die Kommunikation fortgesetzt und der Benutzer kann fortsetzen. Wenn nicht, wechselt der Benutzer zum Anmeldebildschirm wie in Fall 2.

Answer 4

REST ist seiner Natur nach sessionless. Sie müssen beim Anmelden eines Benutzers ein Token generieren. Sie müssen dieses Token auf Ihrem mobilen Client speichern. Für jede Anforderung müssen Sie ein gültiges Token im Anforderungsheader anhängen und auf der Serverseite überprüfen. Wenn das Token abläuft, ist das auf einem Client gespeicherte Token ungültig. Also, Sie müssen sich wegen 401-Antwort erneut anmelden. Wenn Token nicht korrekt ist, musst du 400 antworten. Ich hoffe, dass ich dir behilflich bin.

Answer 5

Sie sollten sich keine Sorgen über die Sitzung von der mobilen Entwicklung Seite machen. Ich weiß nicht viel über iOS, aber in Android verwenden wir SharedPrefrence (Flag, die die Sitzung lokal verwaltet).

Answer 6

Ihr Server sollte vollständig staatenlos sein, und so sollte keine Sitzung gespeichert werden .. ein REST-API ist effektiv nur eine Datenabstraktionsschicht mit optionaler Sicherheit (durch Token)

So Sie API einen Authentifizierungsdienst aussetzen, die antwortet mit einem Berechtigungstoken, das bei nachfolgenden Anforderungen als Kopfzeile verwendet werden soll. Dieses Token sollte eine 1: 1-Beziehung mit jedem Benutzer und Universally Unique sein. Es sollte auch eine Ablaufzeit haben, an der Ihr Server mit einer entsprechenden Fehlerreaktion antwortet und Ihre App anfordert, das Token zu aktualisieren. Dies kann entweder über ein separates Aktualisierungs-Token-System erfolgen oder der Benutzer meldet sich erneut an, um das Token zu aktualisieren .

Es ist die APP, die den Zustand beibehalten sollte, nicht der Server. Der Server ist lediglich für Datenzwecke da und sollte sich daher nicht auf eine sessionbasierte Authentifizierung verlassen.

Answer 7

Eine Sitzung ist "etwas", das auf dem Server lebt. Es kann ein Objekt sein, das Details über den Benutzer speichert (zum Beispiel Sitzungs-ID, Benutzername, E-Mail-Adresse ...) oder andere Daten, die für die Verarbeitung zukünftiger Anfragen benötigt werden (z. B. Details zum Einkaufswagen, Lieferadresse ...).

Das "etwas" ist in der Regel ein Objekt, das im Speicher, in einer Datenbank gespeichert oder sogar serialisiert und im Dateisystem gespeichert werden kann (ich glaube, das ist der Standard in PHP).

Also wenn Sie sagen "Ich weiß nicht, ob die Sitzung in iOS/Android-App beibehalten wird", ich fürchte, das macht keinen Sinn. Nur der Server kann Sitzungen verwalten.

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

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

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

Um mehr über Session-Handling zu lesen und wie benutzerdefinierte Session-Handler erstellen (die in Ihrem Fall erforderlich sein könnten, ein Token aus den Request-Header zu erhalten):
http://php.net/manual/en/function.session-start.php