Si REST les applications sont supposées être sans état, comment gérez-vous les sessions?
J'ai besoin de quelques éclaircissements. J'ai lu des articles sur REST et sur la construction d'applications RESTful. Selon wikipedia, REST lui-même est défini comme étant Representational State Transfer. Je ne comprends donc pas tout ce qui est apatride gobbledeygook que tout le monde continue à vomir.
De wikipedia:
A tout moment, un client peut être en transition entre les états de l'application ou "au repos". Un client à l'état de repos peut interagir avec son utilisateur, mais ne crée aucune charge et ne consomme aucun stockage par client sur l'ensemble des serveurs ou sur le réseau.
Est-ce qu'ils disent juste de ne pas utiliser le magasin de données au niveau de la session/de l'application?
J’obtiens que l’un des objectifs de REST est de rendre l’accès à l’URI cohérent et disponible, par exemple, au lieu de masquer les demandes de pagination dans les messages, le numéro de page d’une demande faisant partie de l’URI GET. Cela a du sens pour moi. Mais il semble qu’on aille trop loin en disant que pas de données par client (données de session) devrait toujours être stocké côté serveur.
Que se passe-t-il si j'avais une file de messages en attente et que mon utilisateur souhaite lire les messages mais, au fur et à mesure de sa lecture, souhaite bloquer certains messages des expéditeurs arrivant pendant la durée de sa session? Ne serait-il pas judicieux de le stocker dans un emplacement côté serveur et de ne laisser au serveur que des messages (ou identifiants de message) non bloqués par l'utilisateur?
Dois-je vraiment envoyer la liste complète des expéditeurs de messages à bloquer chaque fois que je demande la nouvelle liste de messages? La liste de messages pertinente pour moi ne serait/ne devrait même pas être une ressource accessible au public en premier lieu.
Encore une fois, juste essayer de comprendre cela. Quelqu'un s'il vous plaît clarifiez.
Mise à jour:
J'ai trouvé une question de débordement de pile qui ne répond pas tout à fait à la question: Comment gérer l'état dans REST qui indique que l'état du client est important devrait tous être transférés à chaque demande .... Ugg .. semble être beaucoup de frais généraux ... Est-ce vrai ??
L'apatridie signifie que chaque requête HTTP est réalisée de manière totalement isolée. Lorsque le client effectue une requête HTTP, il inclut toutes les informations nécessaires au serveur pour répondre à cette requête. Le serveur ne s'appuie jamais sur les informations des requêtes précédentes. Si cette information est importante, le client devra la renvoyer dans une requête ultérieure. L'apatridie apporte également de nouvelles fonctionnalités. Il est plus facile de distribuer une application sans état sur des serveurs à charge équilibrée. Une application sans état est également facile à mettre en cache.
Il y a en fait deux types d'état. Etat de l'application résidant sur le client et état de la ressource hébergée sur le serveur.
Un service Web doit uniquement se préoccuper de l'état de votre application lorsque vous effectuez une demande. Le reste du temps, il ne sait même pas que vous existez. Cela signifie que chaque fois qu'un client fait une demande, il doit inclure tous les états de l'application, le serveur devra le traiter.
L'état des ressources est le même pour chaque client et sa place appropriée est sur le serveur. Lorsque vous téléchargez une image sur un serveur, vous créez une nouvelle ressource: la nouvelle image a son propre URI et peut être la cible de futures demandes. Vous pouvez récupérer, modifier et supprimer cette ressource via HTTP.
J'espère que cela aide à différencier ce que sont l'apatridie et divers états.
L'explication fondamentale est:
Aucun état de session client sur le serveur.
Par sans état, cela signifie que le serveur ne stocke aucun état concernant la session client du côté serveur.
La session client est stockée sur le client. Le serveur est sans état signifie que chaque serveur peut servir n'importe quel client à tout moment, il n'y a pas de session affinity ou sticky sessions. Les informations de session pertinentes sont stockées sur le client et transmises au serveur selon les besoins.
Cela n'empêche pas les autres services avec lesquels le serveur Web communique de conserver l'état des objets métier tels que les paniers d'achat, mais pas l'état actuel de l'application/de la session du client.
L'état de l'application du client ne doit jamais être stocké sur le serveur, mais transmis du client à tous les endroits qui en ont besoin.
C’est d’où le ST dans RESTE, Transfert d’État. Vous transférez l'état au lieu de le stocker sur le serveur. C’est le seul moyen de s’adapter à des millions d’utilisateurs simultanés. Ne serait-ce que pour des raisons autres que les millions de sessions.
La charge de gestion de session est amortie sur tous les clients, les clients stockent leur état de session et les serveurs peuvent desservir de nombreux ordres de grandeur ou plus de clients de manière sans état.
Même pour un service dont vous pensez que seulement vous aurez besoin parmi des milliers d'utilisateurs simultanés, vous devez néanmoins rendre votre service sans état. Des dizaines de milliers, c’est encore des dizaines de milliers et il y aura un coût en temps et en espace associé.
Stateless est la façon dont le protocole HTTP et le Web en général ont été conçus pour fonctionner. Il s'agit d'une implémentation plus simple et vous avez un seul chemin de code au lieu d'un tas de logique côté serveur pour conserver un tas d'état de session.
Il existe quelques principes de base de mise en œuvre:
Ce sont des principes et non des mises en œuvre, la façon dont vous respectez ces principes peut varier.
En résumé, les cinq principes clés sont:
- Donnez une ID à chaque chose
- Lier les choses ensemble
- Utiliser des méthodes standard
- Ressources avec plusieurs représentations
- Communiquer de manière apatride
Il n'y a rien sur l'authentification ou l'autorisation dans le REST mémoire .
Parce qu'il n'y a rien de différent de l'authentification d'une requête qui est RESTful d'une autre qui ne l'est pas. L'authentification n'est pas pertinente pour la discussion RESTful.
Expliquer comment créer une application sans état pour vos besoins particuliers est too-wide pour StackOverflow.
La mise en œuvre de l'authentification et de l'autorisation en ce qui concerne REST est encore plus précise trop large et diverses approches de mise en œuvre sont expliquées en détail sur Internet en général.
_ {Les commentaires demandant de l'aide/des informations à ce sujet/devraient simplement être marqués comme N'est plus nécessaire}.
Sont-ils en train de dire de ne pas utiliser le magasin de données de session/application?
Non, ils ne disent pas cela d'une manière triviale.
Ils disent ne définissent pas une "session". Ne vous connectez pas. Ne vous déconnectez pas. Fournissez les informations d'identification avec la demande. Chaque demande est seule.
Vous avez encore des magasins de données. Vous avez toujours l'authentification et l'autorisation. Vous ne perdez simplement pas de temps à établir des sessions et à maintenir l'état de session.
Le fait est que chaque requête (a) reste complètement seule et (b) peut être transformée de manière triviale en un parc de serveurs parallèle géant sans travail réel. Apache ou Squid peuvent transmettre des requêtes RESTful aveuglément et avec succès.
Que se passe-t-il si j'avais une file de messages en attente et que mon utilisateur souhaite lire les messages mais, au fur et à mesure de sa lecture, souhaite bloquer certains messages des expéditeurs arrivant pendant la durée de sa session?
Si l'utilisateur souhaite un filtre, indiquez simplement le filtre à chaque demande.
Ne serait-il pas logique que le serveur envoie uniquement des messages (ou identifiants de message) qui ne sont pas bloqués par l'utilisateur?
Oui. Fournissez le filtre dans la demande d'URI RESTful.
Dois-je vraiment envoyer la liste complète des expéditeurs de messages à bloquer chaque fois que je demande la nouvelle liste de messages?
Oui. Quelle peut être la taille de cette "liste des expéditeurs de messages à bloquer"? Une courte liste de PK?
Une requête GET peut être très volumineuse. Si nécessaire, vous pouvez essayer une requête POST même si cela ressemble à une sorte de requête.
Vous avez absolument raison, prendre en charge des interactions totalement sans état avec le serveur impose un fardeau supplémentaire au client. Toutefois, si vous envisagez de redimensionner une application, la puissance de calcul des clients est directement proportionnelle au nombre de clients. Par conséquent, il est beaucoup plus facile de s’adapter à un nombre élevé de clients.
Dès que vous attribuez au serveur une toute petite part de responsabilité pour gérer certaines informations relatives aux interactions d'un client spécifique, la charge peut rapidement augmenter pour consommer le serveur.
C'est un compromis.
Vue historique de la gestion de l'état de l'application utilisateur
Les sessions au sens traditionnel conservent l'état de l'utilisateur dans l'application à l'intérieur du serveur. Il peut s’agir de la page en cours dans un flux ou de ce qui a déjà été entré mais n’a pas encore été conservé dans la base de données principale.
La raison de ce besoin était l’absence de normes du côté client permettant de maintenir efficacement l’état sans créer d’applications ou de plug-ins spécifiques au client (c'est-à-dire spécifiques au navigateur).
Au fil du temps, HTML5 et XML Header Request a normalisé la notion de stockage de données complexes, y compris état de l'application, de manière standard côté client (c'est-à-dire navigateur), sans recourir à des allers-retours entre les serveurs.
Utilisation générale des services REST
Les services REST sont généralement appelés lorsqu'une transaction doit être exécutée ou si elle doit extraire des données.
Les services REST doivent être appelés par l'application côté client et non par l'utilisateur final directement.
Authentifier
Pour toute demande adressée au serveur, une partie de la demande doit contenir le jeton d'autorisation. Son implémentation est spécifique à l'application, mais en général, il s'agit d'une forme d'authentification BASIC ou CERTIFICATE.
L'authentification basée sur le formulaire n'est pas utilisée par les services REST. Cependant, comme indiqué ci-dessus, les services REST ne sont pas destinés à être appelés par l'utilisateur, mais par l'application. L'application doit gérer l'obtention du jeton d'authentification. Dans mon cas, j’ai utilisé des cookies avec JASPIC avec OAuth 2.0 pour me connecter à Google pour l’authentification et une authentification HTTP simple pour des tests automatisés. J'ai également utilisé l'authentification d'en-tête HTTP via JASPIC pour les tests locaux (bien que la même approche puisse être effectuée dans SiteMinder)
Selon ces exemples, l'authentification est gérée côté client (bien que SiteMinder ou Google stockent la session d'authentification de leur côté), rien ne peut être fait à propos de cet état, mais il ne fait pas partie du REST. application de service.
Demandes de récupération
Les demandes de récupération dans REST sont des opérations GET dans lesquelles une ressource spécifique est demandée et peut être mise en cache. Les sessions de serveur ne sont pas nécessaires car la requête contient tout ce dont elle aurait besoin pour récupérer les données: l'authentification et l'URI.
Scripts de transaction
Comme indiqué ci-dessus, l'application côté client appelle elle-même les services REST avec l'authentification qu'elle gère également du côté client.
Cela signifie pour les services REST [si cela est fait correctement] est de prendre une requête unique sur le serveur REST qui contiendra tout ce qui est nécessaire pour une opération utilisateur unique qui effectue tout ce qui est nécessaire dans une transaction unique , a Transaction Script est ce que le motif est appelé.
Cela se fait généralement via une requête POST, mais d'autres, telles que PUT, peuvent également être utilisées.
Beaucoup d'exemples artificiels de REST (j'ai moi-même fait cela) ont essayé de suivre autant que ce qui avait été défini dans le protocole HTTP, après avoir décidé que j'étais plus pragmatique et que je le laissais à GET et POST uniquement . La méthode POST n'a même pas à implémenter le modèle POST-REDIRECT-GET.
Quoi qu’il en soit, comme je l’ai noté ci-dessus, l’application côté client sera celle qui appelle le service et elle appellera uniquement la demande POST avec toutes les données à sa convenance (pas à chaque fois). Cela empêche les demandes constantes au serveur.
Vote
Bien que REST puisse également être utilisé pour l'interrogation, je ne le recommanderai pas, sauf si vous devez l'utiliser pour des raisons de compatibilité de navigateur. Pour cela, j'utiliserais WebSockets pour lequel j'avais également conçu un contrat d'API . CometD est une autre alternative pour les anciens navigateurs.
REST est très abstrait. Il est utile d’avoir de bons exemples simples et réels.
Prenez par exemple toutes les principales applications de médias sociaux - Tumblr, Instagram, Facebook et Twitter. Ils ont tous une vue qui défile à tout jamais: plus vous faites défiler le texte, plus vous voyez de contenu, plus loin dans le passé. Cependant, nous avons tous vécu ce moment où vous avez perdu votre chemin et où l'application vous a remis à zéro. Comme si vous quittiez l'application, lorsque vous la rouvrez, vous êtes de nouveau au sommet.
La raison en est que le serveur n'a pas stocké l'état de votre session. Malheureusement, votre position de défilement vient d'être enregistrée dans RAM sur le client.
Heureusement, vous n'avez pas à vous reconnecter lorsque vous vous reconnectez, mais c'est uniquement parce que votre certificat de connexion stocké côté client n'a pas expiré. Supprimez et réinstallez l'application, et vous devrez vous reconnecter, car le serveur n'a pas associé votre adresse IP à votre session.
Vous n'avez pas de session de connexion sur le serveur, car ils respectent REST.
À présent, les exemples ci-dessus n’impliquent aucun navigateur Web, mais les applications communiquent via HTTPS avec leurs serveurs hôtes. Mon argument est que REST ne doit pas nécessairement impliquer les cookies, les navigateurs, etc. Il existe différents moyens de stocker l'état de session côté client.
Mais parlons un instant des navigateurs Web, car cela apporte un autre avantage majeur de REST dont personne ici ne parle.
Si le serveur a essayé de stocker l'état de session, comment est-il supposé identifier chaque client?
Il ne pouvait pas utiliser son adresse IP, car de nombreuses personnes pourraient utiliser cette même adresse sur un routeur partagé. Alors comment alors?
Il ne peut pas utiliser l'adresse MAC pour de nombreuses raisons, notamment parce que vous pouvez être connecté simultanément à plusieurs comptes Facebook différents sur différents navigateurs en plus de l'application. Un navigateur peut facilement prétendre en être un autre et les adresses MAC sont tout aussi faciles à usurper.
Si le serveur doit stocker un état côté client pour vous identifier, il doit le stocker dans RAM plus longtemps que le temps nécessaire au traitement de vos demandes, sinon il doit mettre en cache ces données. Les serveurs ont des quantités limitées de RAM et de cache, sans parler de la vitesse du processeur. L'état côté serveur s'ajoute aux trois, de manière exponentielle. De plus, si le serveur doit stocker un état quelconque de vos sessions, il doit le stocker séparément pour chaque navigateur et application avec lesquels vous êtes actuellement connecté, ainsi que pour chaque appareil différent que vous utilisez.
Alors ... j'espère que vous voyez maintenant pourquoi REST est si important pour l'évolutivité. J'espère que vous comprendrez pourquoi l'état de la session côté serveur est synonyme d'évolutivité du serveur, ce que sont les enclumes soudées qui permettent l'accélération d'une voiture.
Là où les gens se perdent, c'est en pensant que "état" désigne, par exemple, les informations stockées dans une base de données. Non, cela concerne toutes les informations devant figurer dans la RAM du serveur lorsque vous les utilisez.
Je vois que le problème fondamental ici est de mélanger Session avec État. Et alors que REST indique que vous ne devez PAS stocker le State sur le serveur, rien ne vous empêche de stocker un utilisateur Session.
La gestion de État sur le serveur signifie que votre serveur sait exactement ce que fait le client (quelle page il visualise dans quelle section de l'application). Et c'est ce que vous ne devriez pas avoir besoin de faire.
Je suis d'accord avec les autres personnes qui disent que vous devriez garder le stockage de session à une taille minimale. et bien que ce soit du bon sens, cela dépend en fait de l'application . Donc, en bref, vous pouvez toujours conserver une session avec des données en cache pour traiter les requêtes avec moins de charge sur le serveur, et gérer l'authentification en fournissant une jeton d'authentification/d'accès à utiliser par le client. Chaque fois que la session/le jeton a expiré, générez-en un nouveau et demandez au client de l'utiliser.
Quelqu'un pourrait dire que le client devrait mieux générer le jeton. Je dis que cela fonctionne dans les deux sens, et cela dépend de l'application et de la personne qui va travailler avec l'API.
Conserver également des données de session sensibles sur le serveur devrait être la bonne façon de le faire. Vous ne pouvez pas faire confiance au client pour conserver son panier contenant (par exemple) un champ nommé "isFreeGift". Ces informations doivent être conservées sur le serveur.
Le lien vidéo fourni par Santanu Dey dans sa réponse est utile. Regardez-le si vous ne l'avez pas.
Juste une note de côté: il semble que toutes les réponses déjà données semblent ignorer le fait que certaines opérations peuvent entraîner une charge importante sur le serveur. Ceci est pertinent en termes de consommation d'énergie, de matériel et de coût (pour les serveurs loués par cycle de processeur). Un bon développeur ne doit pas être paresseux dans l'optimisation de son application, même si l'opération peut être effectuée très rapidement sur un processeur moderne sur un serveur loué pour lequel ils ne paient pas sa facture d'électricité et de maintenance.
Bien que la question date de quelques années, j'espère que ma réponse sera toujours utile.
Sans état signifie que l'état du service ne persiste pas entre les demandes et les réponses ultérieures. Chaque demande porte ses propres informations d'identification d'utilisateur et est authentifiée individuellement. Mais dans l'état, chaque demande est connue de toute demande préalable. Toutes les demandes avec état sont orientées session, c’est-à-dire que chaque demande doit connaître et conserver les modifications apportées aux demandes précédentes.
L'application bancaire est un exemple d'application avec état. Lorsque l'utilisateur se connecte pour la première fois, effectue la transaction et se déconnecte. Si après la déconnexion, l'utilisateur essaie d'effectuer la transaction, il ne pourra pas le faire.
Oui, le protocole http est essentiellement un protocole sans état, mais pour le rendre dynamique, nous utilisons des cookies HTTP. Donc, SOAP est par défaut. Mais cela peut aussi être rendu stateful, cela dépend du cadre que vous utilisez.
HTTP est sans état, mais nous pouvons néanmoins maintenir la session dans notre application Java en utilisant un mécanisme de suivi de session différent.
Oui, nous pouvons également maintenir la session dans le service Web, que ce soit REST ou SOAP. Cela peut être implémenté en utilisant n'importe quelle bibliothèque tierce ou par vous-même.
Extrait de http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap
Jetez un coup d'œil à cette présentation.
Selon ce modèle, créez des ressources de repos transitoires pour gérer l’état si et quand cela est vraiment nécessaire. Évitez les sessions explicites.
La principale différence entre stateless et stateful réside dans le fait que les données sont renvoyées au serveur à chaque fois. Dans le cas d'un état sans état, le client doit fournir toutes les informations, de sorte qu'il peut être nécessaire de transmettre un grand nombre de paramètres à chaque demande. Dans Stateful, le client transmet ces paramètres une fois et ceux-ci sont gérés par le serveur jusqu'à ce qu'ils soient à nouveau modifiés par le client.
IMO, API doit être sans état, ce qui permet une montée en puissance très rapide.
Vous devez gérer la session client côté client. Cela signifie que vous devez envoyer des données d'authentification à chaque demande et que vous avez probablement, mais pas nécessairement, un cache en mémoire sur le serveur, qui associe les données d'authentification aux informations utilisateur telles que l'identité, les autorisations, etc.
Cette contrainte REST statelessness est très importante. Sans appliquer cette contrainte, votre application côté serveur ne fonctionnera pas bien scale , car le maintien de chaque session client sera son talon d'Achille .
Tout le concept est différent ... Vous n'avez pas besoin de gérer les sessions si vous essayez d'implémenter le protocole RESTFul. Dans ce cas, il est préférable d’effectuer une procédure d’authentification à chaque requête (alors que les performances sont gênantes en termes de performances - le hachage du mot de passe serait un bon exemple. Pas très grave ...). Si vous utilisez des sessions - comment pouvez-vous répartir la charge sur plusieurs serveurs? Je parie que le protocole RESTFul est destiné à éliminer les sessions de quelque manière que ce soit - vous n'en avez pas vraiment besoin ... C'est pourquoi on l'appelle "apatride". Les sessions ne sont requises que lorsque vous ne pouvez pas stocker autre chose qu'un cookie côté client après la création d'une requête (utilisez par exemple un ancien navigateur ne prenant pas en charge JavaScript/HTML5). Dans le cas d'un client RESTFul "complet", il est généralement prudent de stocker base64(login:password) côté client (en mémoire) jusqu'à ce que l'application soit encore chargée. L'application est utilisée pour accéder au seul hôte et le cookie ne peut pas être compromis par la scripts tiers ...
Je recommanderais stronly de désactiver l'authentification par cookie pour les services RESTFul ... consultez Basic/Digest Auth - cela devrait suffire pour les services basés sur RESTFul.
Sans état, cela signifie que l'état ou les métadonnées de la demande ne sont pas conservés côté serveur. En maintenant chaque demande ou l'état de l'utilisateur sur le serveur, cela entraînerait des goulots d'étranglement en termes de performances. Le serveur est simplement demandé avec les attributs requis pour effectuer des opérations spécifiques.
Pour gérer des sessions ou donner une expérience personnalisée aux utilisateurs, il est nécessaire de conserver certaines métadonnées ou l'état des préférences probables de l'utilisateur, ainsi que l'historique des demandes passées. Cela peut être fait en conservant des cookies, des attributs cachés ou dans un objet de session.
Cela peut maintenir ou garder trace de l'état de l'utilisateur dans l'application.
J'espère que cela t'aides!
REST est sans état et ne conserve aucun état entre les demandes. Les cookies/en-têtes du client sont configurés pour conserver l'état de l'utilisateur comme une authentification. Dites que le nom d'utilisateur/mot de passe du client est validé par un mécanisme d'authentification de troisième partie - gerneation OTP de deuxième niveau, etc. Une fois que l'utilisateur est authentifié - les en-têtes/cookies arrivent au point de terminaison du service exposé et nous pouvons supposer que l'utilisateur est authentifié puisque l'utilisateur vient avec des en-têtes/cookies valides. . Maintenant, certaines informations d’utilisateur comme IP sont conservées dans le cache et ensuite, si la demande provient du même IP (adresse MAC) pour les ressources répertoriées, l’utilisateur est autorisé. Et le cache est maintenu pendant un certain temps qui sera invalidé une fois le temps écoulé. Ainsi, le cache peut être utilisé ou les entrées de base de données peuvent être utilisées pour conserver les informations n/b des demandes.
Il n'y a pas de cuillère. Ne pensez pas à l'état d'apatridie comme "envoyer tous vos fichiers au serveur encore et encore". En aucune façon. Il y aura un état, toujours - la base de données elle-même est une sorte d'état, après tout, vous êtes un utilisateur enregistré. Ainsi, tout ensemble d'informations côté client ne sera pas valide sans le côté serveur. Techniquement, vous n'êtes jamais vraiment apatride.
Mais ce que vous pouvez faire, et ce qui a du sens, est de réduire au minimum l’empreinte de votre serveur Web. Des langages comme PHP rendent très facile le remplissage complet de tout le stockage de la session; vous pouvez le faire, mais si vous avez plusieurs serveurs Web, ils doivent utiliser quelque chose qui leur est partagé (NFS, Redis, Memcached, quelque chose) pour que votre demande suivante sache ce que vous avez fait en un clic plus tôt. C'est à cause de l'équilibrage de la charge: vous risquez de vous retrouver sur un autre serveur Web lors de votre prochaine requête. Et même s’il DOIT y avoir un stockage partagé (principalement parce qu’ils devront dire si vous êtes connecté ou non), vous ne devez pas l’utiliser comme base de données alternative. Ce n'est pas pour ça.
Alors vous dites, garder le stockage de session au minimum?
Encore une fois, c'est votre décision. Vous pouvez y stocker des éléments pour des raisons de performances (la base de données est presque toujours plus lente que Redis), vous pouvez stocker des informations de manière redondante, implémenter votre propre mise en cache, peu importe - gardez simplement à l'esprit que les serveurs Web auront une charge plus importante si vous stockez beaucoup de déchets. sur eux. En outre, s’ils se cassent sous de lourdes charges (et ils le feront), vous perdrez des informations précieuses; Avec la façon de penser REST, dans ce cas, tout ce qui se passe est que le client envoie à nouveau la même demande (!) et il est servi cette fois-ci.
Comment le faire correctement alors?
Pas de solution unique pour tous ici. Je dirais de choisir un niveau d'apatridie et d'y aller. Les sessions peuvent être aimées par certains et détestées par d'autres, mais elles ne vont nulle part. Avec chaque demande, envoyez autant d’informations que nécessaire, un peu plus peut-être; mais n'interprétez pas l'apatridie comme n'ayant pas de session, ni comme ouvrant une session à chaque fois. D'une manière ou d'une autre, le serveur doit savoir que c'est vous; Les identifiants de session PHP sont un bon moyen, les jetons générés manuellement en sont un autre.
Pensez et décidez, ne laissez pas les tendances du design penser pour vous.
Lorsque vous développez un service RESTful, vous devez vous authentifier pour pouvoir vous connecter. Une option possible serait d'envoyer le nom d'utilisateur et le mot de passe chaque fois que vous avez l'intention d'effectuer une action de l'utilisateur. Dans ce cas, le serveur ne stockera pas de données de session.
Une autre option consiste à générer un identifiant de session sur le serveur et à l'envoyer au client, afin que le client puisse envoyer l'identifiant de session au serveur et s'authentifier avec cet identifiant. Cela est beaucoup plus sûr que d'envoyer un nom d'utilisateur et un mot de passe à chaque fois, car si quelqu'un obtient la main sur ces données, il peut emprunter l'identité de l'utilisateur jusqu'à ce que le nom d'utilisateur et le mot de passe soient modifiés. Vous pouvez dire que même l'identifiant de session peut être volé et que l'utilisateur sera personnifié dans ce cas, et vous avez raison. Cependant, dans ce cas, l'usurpation de l'identité de l'utilisateur ne sera possible que si l'identifiant de session est valide.
Si l'API RESTful attend un nom d'utilisateur et un mot de passe pour pouvoir changer de nom d'utilisateur et de mot de passe, même si quelqu'un usurpe l'identité de l'utilisateur à l'aide de l'ID de session, le pirate ne pourra pas verrouiller le véritable utilisateur.
Un identifiant de session peut être généré par verrouillage unidirectionnel (chiffrement) de quelque chose qui identifie l'utilisateur et en ajoutant l'heure à l'identifiant de session, ce qui permet de définir le délai d'expiration de la session.
Le serveur peut ou non stocker les identifiants de session. Bien entendu, si le serveur stocke l'identifiant de session, il enfreindrait les critères définis dans la question. Cependant, il est seulement important de s'assurer que l'identifiant de session peut être validé pour l'utilisateur donné, ce qui ne nécessite pas de stocker l'identifiant de session. Imaginez un moyen de crypter le courrier électronique à sens unique, d’identifiant d’utilisateur et de certaines données privées propres à l’utilisateur, comme la couleur favorite, ce serait le premier niveau et, d’une manière ou d’une autre, ajouter la date du nom d’utilisateur à la chaîne chiffrée et appliquer un code à deux. manière de cryptage. En conséquence, lorsqu'un identifiant de session est reçu, le deuxième niveau peut être déchiffré pour pouvoir déterminer le nom d'utilisateur que l'utilisateur prétend être et si l'heure de la session est correcte. Si cela est valide, le premier niveau de cryptage peut être validé en le refaisant et en vérifiant s'il correspond à la chaîne. Il n'est pas nécessaire de stocker des données de session pour y parvenir.