Comment gérer la session d'un utilisateur connecté à partir de l'application mobile en PHP?

Je suis un programmeur PHP par la profession. Donc, je n'ai pas la moindre idée sur iOS et Android codage.

Le scénario est, il y est un site web développé à l'aide d'un Réseau Social logiciel PHP intitulé "PHPFox".

Il y a maintenant deux applications mobiles qui exactement reproduit les fonctionnalités de ce site. Une application mobile est en iOS et un autre est en Android.

Donc, j'ai écrit une série d'Api RESTful où je suis l'acceptation de la requête à partir de l'application mobile, analyser la demande, transmettre la requête de paramètres à la fonction qui fait le même travail pour le site web, obtenir une réponse à partir de cette fonction, de le convertir en format JSON et l'a renvoyé à l'application mobile. Pour iOS et Android, je suis en utilisant le même ensemble d'API REST fichiers.

Lorsque l'utilisateur se connecte, le RESTE de l'API de connexion est appelé. Finalement, le PHPFox fonction pour l'authentification est appelée, un jeton de sécurité est généré ainsi que quelques autres données de l'utilisateur. Avec chaque connexion les différents jeton de sécurité est généré par PHPFox. Ces données sont reprises dans la session. Maintenant, chaque fois que j'appelle de l'une des fonctions par le biais de tout REPOS fichier API de l'émission de jeton de sécurité généré au moment de la connexion est vérifiée et seulement au moment de la vérification de jeton de la PHPFox fonction est appelée. Ce processus de vérification est effectué en interne par PHPFox. Donc pas besoin de passer le jeton de sécurité explicitement ou implicitement de tout REPOS appel d'API.

Jusqu'à maintenant, tout fonctionne très bien.

Mon doute commence à partir d'ici. Je ne sais pas si la séance est maintenue dans iOS/Android app. Donc, si la session sur le serveur c'est à dire PHPFox obtient expiré alors ce qui va se passer à l'application? Sera-ce crash? Permettra à l'utilisateur d'avoir à vous connecter à nouveau? Si l'utilisateur tue l'application sur le périphérique et vient de nouveau à l'application, a-t-il à faire le processus de connexion à nouveau?

Il y a trop de doutes dans mon esprit. Je reçois totalement confondu avec ces choses.

Quelqu'un peut s'il vous plaît mettre davantage l'accent sur la question que je me pose? Ce serait vraiment génial si vous pouviez expliquer en détail.

Grâce.

  • donc, finalement, comment êtes-vous de maintien des sessions, veuillez répondre je suis bloqué dans ce même problème ??
InformationsquelleAutor PHPLover | 2015-02-21
  1. 55

    RESTE est sessionless pour sa nature. Vous avez besoin de générer un jeton lorsque l'utilisateur connecté. Vous devez enregistrer ce jeton sur votre mobile client.
    Pour chaque demande, vous devez joindre un jeton valide en-tête de la demande et vérifier à côté serveur.
    Si l'expiration de ce jeton, le jeton stockées sur un client n'est pas valide. Ainsi, vous devez vous connecter à nouveau en raison de réponse 401. Si le jeton c'est pas correct, vous devez responde 400.
    J'espère que je suis utile pour vous.

    • Le jeton de vous décrire les sons exactement le même comme un ID de session.
    • oui, mais dites-moi une chose que vous pouvez vérifier sur la plupart des applications android qu'ils ne demandent jamais de vous connecter à nouveau maintenant, est-ce qu'ils ne pas définir n'importe quel moment de l'expiration ou ils font quoi ??
    • Peut-être qu'ils pourraient avoir à développer un système de comprendre si un jeton est expiré et puis donner un jeton de retour à son application. Ou le jeton n'expirent jamais. Je vous suggère de lire quelque chose à propos de oauth.
    • C'est la beauté de l'aide de Jetons! Contrairement aux séances, ils n'expire jamais, implicitement, à moins que l'on tue de façon explicite.
    • C'est vrai! Mais c'est une bonne pratique que d'un jeton expirent après une période. JSON Web Jeton est le chemin!
    InformationsquelleAutor valeriocomo
  2. 20

    Contrairement aux navigateurs web, les applications iOS et android ne permettent pas de maintenir les sessions. Généralement, une fois qu'un utilisateur s'est connecté (connexion les informations d'identification vérifiées à partir du serveur), ses identifiants de connexion sont enregistrés sur le côté client. L'application récupère les données à partir du serveur à l'aide de session RESTE moins d'appels d'api. C'est de cette façon la plupart du temps c'est fait dans des applications mobiles.

    Cependant, si vous souhaitez que le serveur de session et application mobile vont main dans la main (que je n'ai pas pense que c'est une bonne idée), la voie est

    1) Lorsque l'utilisateur se connecte, un jeton de sécurité est généré sur le serveur et enregistrées sur le serveur et côté client.

    2) L'application mobile sera en mesure de communiquer avec le serveur tant que le jeton de sécurité est valide.

    3) Lors de la session expire, le jeton de sécurité devient non valide. Maintenant, il doit y avoir une entente entre le serveur et le client à propos de la réponse lors de la session a expiré. Maintenant l'application mobile doit rediriger l'utilisateur vers la page de connexion à nouveau. L'utilisateur se connecte à nouveau, puis communiquer avec le serveur. Cela devrait se produire chaque fois que la session a expiré.

    • Merci pour votre réponse mais je pense que vous ne comprenez pas mon point de vue complètement. Lorsque l'utilisateur se connecte à partir de l'appareil par iOS/Android app de la session sur le serveur de commencer, le PHPFox génère un jeton de sécurité qui est en jeu dans cette session. Lors de chaque demande ultérieure, à partir de l'app cette émission de jeton de sécurité est vérifiée par PHPFox en interne pour sécuriser la fonctionnalité. Mon doute est de savoir si l'utilisateur n'a pas déconnecter de l'application et de la session sur le serveur est dépassé c'est à dire PHPFox session obtient une cravate, alors que dois-je faire? Pour cela, je pense que la session doit être maintenue sur l'app côté aussi.
    • Et la session à partir de l'app doit être synchronisé avec la session à partir du serveur. Seulement alors, le problème ne va pas augmenter. En bref, je pense que les deux sessions doivent travailler main dans la main. Suis-je la corriger?
    InformationsquelleAutor Fawad Masud
  3. 15

    Si vous êtes en utilisant Oauth 2 pour athentication, ici, c'est la commune de l'installation:

    • Utilisateur se connecte sur l'application mobile
    • Si les informations d'identification sont ok, le serveur renvoie le jeton d'accès, un jeton d'actualisation et le jeton de la vie d'
    • L'application mobile stocke ces valeurs + timestamp actuel
    • Sur le côté du serveur, d'un ramasse-miettes est configuré pour effacer expiré jetons
    • Avant de faire des appels de l'api, l'application mobile vérifie si le jeton est sur le point d'expirer (avec l'aide des valeurs stockées). Si le jeton est sur le point d'expirer, l'application envoie le jeton d'actualisation qui indique au serveur de générer un nouveau jeton d'accès
    • Si vous souhaitez que les utilisateurs de rester connectés, l'application peut être configuré pour vérifier le jeton d'accès périodiquement et faire une nouvelle demande si c'est rassis

    Espère que cette aide.

    Acclamations

    • qu'est-ce que l'utilisation de l'actualisation jeton si quelqu'un peut voler votre jeton, alors il/elle peut aussi voler vos actualiser jeton ??
    • l'actualisation de jetons peut être révoquée. Ces sont généralement couplés à court vécu des jetons d'accès comme l'auto codé jetons (JWTs) qui ne peut pas être révoqué manuellement.
    InformationsquelleAutor Valéry
  4. 8

    Votre serveur devrait être complètement apatrides, et donc pas de session doivent être stockés.. une API REST est effectivement juste une couche d'abstraction de données avec l'option de sécurité (par jeton)

    Si vous API exposer un service d'authentification, qui répondra avec un jeton d'Autorisation pour être utilisé sur les demandes ultérieures comme en-tête, ce jeton doit être un 1to1 relation avec l'utilisateur, et Universellement Unique. Il doit également avoir une date d'expiration, à quel point votre serveur répond avec d'erreur approprié de la réponse de la demande de votre app pour actualiser le jeton, qui peut être fait soit par le biais d'une actualisation système de jetons, ou de demander à l'utilisateur se connecte à nouveau à actualiser le jeton.

    C'est l'APPLICATION qui doit maintenir l'état, et non sur le serveur. Le serveur est seulement là pour les données de fins, et il ne faut pas compter sur n'importe quel type de session en fonction de l'authentification.

    • L'inconvénient de cette approche est que le serveur ne peut pas expirer le jeton si ce n'est pas de le ranger.
    • Bien sûr, le serveur est de stocker le jeton, le serveur a besoin de stocker le jeton d'authentifier le client contre... mais c'est tout à son stockage, il ne devrait pas être le stockage de tout autre session de détails.
    • Désolé, je pensais que vous vouliez dire, complètement apatrides comme JWT d'authentification. Mais vous ne signifie maintenir l'état de ce que le client a ce jeton juste dans une base de données non via une session présentielle.
    InformationsquelleAutor RaggaMuffin-420
  5. 4

    Vous ne devriez pas vous soucier de la session du développement mobile côté.Je ne sais pas beaucoup sur iOS, mais sur Android, nous utilisons SharedPrefrence (Drapeau qui maintient la session localement).

    • Très vrai avec android!
    InformationsquelleAutor Puneet Ahuja
  6. 3

    Je n'ai pas d'expérience de travail avec PHPFox, mais c'est la façon dont un mobile frontend, idéalement, devrait gérer les problèmes:

    Cas 1: l'application Mobile activement parler au serveur:

    • Délai d'expiration de Session timbre garde cogner et de la session reste en vie.

    Cas 2: application Mobile active sans aucune communication du serveur (par exemple, des appels téléphoniques entrants, se déplaçant entre les apps, etc.):

    • De session sur le serveur peut ou peut ne pas timeout.
    • Cas de dépassement de délai, suivant la requête au serveur échoue auth et retourner une erreur.
    • Application consomme cette erreur et gracieusement redirige vers l'écran de connexion avec un message toast instamment à l'utilisateur de se connecter.
      (Ce qui se passe dans mon application bancaire)

    Cas 3: l'Utilisateur tue l'application sur le périphérique et relance c':

    • L'application doit stocker le jeton soit dans sqllite ou partagé préférences. (Toujours connecté applications de cette approche)
    • Lors de la relance, l'app peut interroger le serveur avec le presistent jeton.
    • Si la session est en vie, la communication passe par et l'utilisateur peut
      continuer. Si non, l'utilisateur passe à l'écran de connexion comme dans le Cas 2.
    InformationsquelleAutor Sanand Sule
  7. 3

    Une session est "quelque chose" qui vit sur le serveur. Il peut être un objet à l'enregistrement des détails sur l'utilisateur (par exemple l'id de session, le nom d'utilisateur, adresse email,...) ou d'autres données qui seront nécessaires pour traiter les demandes futures (comme panier détails, adresse de livraison...).

    Que "quelque chose" est en général un objet, qui peut être stocké dans la mémoire, dans une base de données ou même sérialisé et enregistré dans le système de fichiers (je crois que c'est la valeur par défaut en PHP).

    Donc quand vous dites "je ne sais pas si la séance est maintenue dans iOS/Android app", je crains que ne fait pas sens. Seul le serveur peut maintenir les sessions.

    Généralement, la seule chose que le client sait (navigateur web ou application mobile) est l'id de session (dans la forme d'un jeton ou le GUID). C'est la seule chose que le client/application ne faut pas oublier, et elle doit être envoyée à côté d'une requête au serveur.

    Il pourrait être stockée dans un cookie et/ou envoyés au serveur en tant qu'en-tête de requête.

    Le serveur va lire l'id de session/jeton à partir de ces cookies ou d'en-tête et permettra de récupérer la session détails de l'endroit où il stocke les sessions (système de fichiers, la mémoire ou de la base de données). Qu'est ce qui se passe derrière la scène lorsque vous appelez session_start().

    Pour en savoir plus sur le gestionnaire de session et comment créer le gestionnaire de session personnalisé (ce qui pourrait être nécessaire dans votre cas pour obtenir un jeton de les en-têtes de requête):

    http://php.net/manual/en/function.session-start.php

    InformationsquelleAutor Alex Sanséau