C'est peut-être une question compliquée, mais j'essaie de mieux comprendre l'apatridie.
D'après ce que j'ai lu, les applications Web devraient être sans état, ce qui signifie que chaque demande est traitée comme une transaction indépendante. Par conséquent, les cookies de session et les cookies doivent être évités (car ils sont tous deux à état dynamique). Une meilleure approche consiste à utiliser des jetons, qui sont sans état, car rien n’est stocké sur le serveur.
J'essaie donc de comprendre comment les applications Web peuvent être sans état si des données sont conservées pour ma session (telles que des éléments dans un panier). Celles-ci sont-elles réellement stockées dans une base de données quelque part, puis purgées périodiquement? Comment cela fonctionne-t-il lorsque vous utilisez un jeton au lieu de cookies?
Et puis, comme question connexe, les principaux sites Web (Amazon, Google, Facebook, Twitter, etc.) sont-ils réellement sans état? Utilisent-ils des jetons ou des cookies (ou les deux)?
Réponses:
"les applications Web doivent être sans état" doit être compris comme "les applications Web doivent être sans état, sauf s'il existe une très bonne raison d'avoir un état" . Un "panier" est une fonctionnalité dynamique par conception, et le nier est tout à fait contre-productif. L'intérêt du modèle de panier d'achat est de préserver l'état de l'application entre les demandes.
Une alternative que je pourrais imaginer en tant que site Web sans état et implémentant un panier serait une application d'une seule page qui garde le panier entièrement côté client, récupère les informations sur le produit avec des appels AJAX, puis les envoie au serveur en une fois lorsque l'utilisateur effectue une commande. Mais je doute avoir déjà vu quelqu'un le faire, car cela ne permet pas à l'utilisateur d'utiliser plusieurs onglets de navigateur et ne conserve pas son état lorsqu'ils le ferment par inadvertance. Bien sûr, il existe des solutions de contournement telles que l’utilisation de localstorage, mais vous avez à nouveau l’état, uniquement sur le client plutôt que sur le serveur.
Chaque fois que vous avez une application Web nécessitant de conserver des données entre les pages vues, vous le faites généralement en introduisant des sessions. La session à laquelle une demande appartient peut être identifiée par un cookie ou par un paramètre d'URL que vous ajoutez à chaque lien. Les cookies doivent être préférés car ils gardent vos URL plus pratiques et empêchent votre utilisateur de partager accidentellement une URL avec l'identifiant de session qu'il contient. Mais avoir des jetons d'URL comme solution de secours est également vital pour les utilisateurs qui désactivent les cookies. La plupart des frameworks de développement Web ont un système de gestion de session qui peut le faire directement.
Du côté du serveur, les informations de session sont généralement stockées dans une base de données. La mise en cache en mémoire côté serveur est facultative. Cela peut grandement améliorer le temps de réponse, mais ne vous permettra pas de transférer des sessions entre différents serveurs. Donc, vous aurez besoin d'une base de données persistante comme solution de secours.
Est-ce qu'ils vous permettent de vous connecter? Lorsque vous fermez ensuite l'onglet et revenez sur le site, êtes-vous toujours connecté? Si vous l'êtes, ils utilisent des cookies pour préserver votre identité entre les sessions.
la source
Il est vrai que les applications Web doivent être sans état. Cependant, les variables de session, les cookies et les jetons n'enfreignent pas cette règle lorsqu'ils sont tous stockés sur le client (navigateur Web). Ils peuvent être des paramètres dans la requête.
Voici un modèle simplifié:
Cela pourrait fonctionner pour Software Engineering Stack Exchange . Cette réponse que je tape fait partie de l'état de mon navigateur Web. Tant que c'est le seul endroit où il se trouve, il n'est accessible à personne d'autre que moi. Mais dès que je frappe,
Post your Answermon navigateur l’envoie au serveur Web. Le serveur Web traite la publication sans utiliser aucun état. Il apprend qui je suis à partir de mon navigateur et de la base de données. Une fois la vérification de mon message terminée et son ajout à la base de données, le serveur Web oublie rapidement mes informations.C'est ce que veut dire apatride. Le serveur n'est pas responsable de se souvenir de cela. Ce n'est pas son travail.
Cela présente de nombreux avantages. Si le serveur Web présente une fuite de mémoire, elle est détectable car son empreinte mémoire ne devrait pas augmenter. Si le serveur Web se bloque, mon identité ne va pas avec. Si une personne tente de faire une attaque par déni de service, elle ne peut pas utiliser les ressources d'état du serveur Web pour le faire, car le serveur Web ne leur alloue aucun état entre les sessions. Tout cela vise à rendre le serveur Web stable. De cette façon, quand il commence à fonctionner, il continue à fonctionner.
Bien sûr, je consomme des ressources dans la base de données, mais ces ressources ont d'abord été vérifiées par rapport à une réserve stable sur laquelle nous pouvons compter pour protéger la base de données du Web sauvage et laineux: le serveur Web apatride et respectant les règles de gestion.
la source
Absurdité. Les demandes Web doivent être sans état. Ou plus précisément, les requêtes Web sont sans état.
Mais dire qu'une application entière doit être apatride est un non-sens.
Oui, exactement . Ou plus précisément, oui, nécessairement . Sur HTTP, chaque demande est intrinsèquement indépendante de toutes les autres demandes. L'ajout de "statefulness" à HTTP nécessite que vous identifiiez, stockiez et récupériez explicitement "state" pour chaque requête "stateful". Et cela demande des efforts, diminue les performances et ajoute à la complexité.
Et, pour ces raisons, chaque demande qui peut être apatride "devrait" être apatride.
Quelques éléments: Les jetons peuvent également être liés au stockage de session. Les cookies ne doivent pas nécessairement être liés au stockage de session. Les jetons sont souvent stockés dans des cookies. Et parfois, une session est simplement le bon outil pour le travail.
Cela signifie qu'au moins parfois , les sessions et les cookies sont tout aussi "meilleurs" que les jetons!
Eh bien c'est ça. C'est ce que le dogme de "l'apatridie" est vraiment. Bien que, pour être clair, il ne s’agisse pas de stocker "rien" sur le serveur, il s’agit de ne pas stocker l’ état de la session sur le serveur.
Ma boîte de réception Gmail est dans un état, par exemple. Et il vaut bien mieux que ce soit stocké sur le serveur! Mais ce n'est pas l' état de la session .
Ainsi, au lieu de disposer de serveurs capables de prendre un petit identifiant et de déterminer qui vous êtes et ainsi de suite, les applications sans état veulent vous rappeler qui vous êtes et ce que vous faites avec chaque requête sanglante. L'état de l'application existe toujours, le client est simplement responsable de la conserver.
Maintenant, si cet état est petit, c'est probablement OK. Dans certains cas, c'est très bien.
Et puis, bien sûr, il y a des choses que nous nous attendons simplement à être stateful
Deux options. Ou vous avez une session, ou vous êtes dans le déni!
... Mais sérieusement. Vous ne devriez normalement pas stocker un panier dans un cookie. Quelque chose comme un panier d'achat sera soit stocké dans une session "traditionnelle", soit en tant
Cartqu'objet, avec une sorte d'identifiant que le serveur utilisera pour extraire celui-ci dans les requêtes suivantes. Un peu comme une ... euh ... euh ... session ...Sérieusement, il existe une grande partie de ce que nous appelons "étatfulness" lorsque deux agents en communication peuvent contextualiser des messages dans une conversation. Et une session, traditionnellement comprise, est ce que nous appelons généralement le mécanisme par lequel cela se produit.
Je dirais que, que vous utilisiez des jetons ou des "sessions", pour chaque demande traitée par votre serveur, vous devez soit contextualiser cette demande pour la remplir, soit ne pas le faire. Si le contexte n'est pas nécessaire, ne le récupérez pas. Si le contexte est nécessaire, vous feriez mieux de l'avoir à proximité!
Probablement les deux. Mais, en général, ils font exactement ce que vous faites: ils configurent les cookies pour identifier les enregistrements "d'état" dans des bases de données "session" massives.
Dans la mesure du possible, je soupçonne qu'ils transforment les revendications d'identité de base en "jetons" de courte durée pour éviter des conflits inutiles sur le stockage centralisé. Cependant, le fait que nombre de ces services me permettent de "me déconnecter de tous les autres sites" est un bon indicateur que, s'ils utilisent des jetons, ils sont au moins "pris en charge" par un modèle de session semi-traditionnel. .
la source
L'état de mémoire n'est pas nécessairement une mauvaise chose, mais vous devez comprendre la différence entre les applications avec état et sans état. En bref, les applications avec état conservent des informations sur la session en cours, contrairement aux applications sans état. Les informations stockées de manière permanente dans le cadre d'un compte d'utilisateur peuvent ou non être stockées dans une session, mais le stockage d'informations relatives à un compte d'utilisateur ne confère pas à l'application un état dynamique. La mise en état nécessite que le serveur conserve des informations sur la session de l'utilisateur actuel, au-delà de ce que le navigateur client gère. Par exemple, un client peut s'authentifier et recevoir un cookie JSESSIONID, qu'il envoie ensuite au serveur à chaque demande. Si le serveur commence à stocker des éléments dans l'étendue de session de l'application en fonction de ce JSESSIONID, il devient dynamique.
Apatridie
Par sans état, nous voulons dire que le serveur et le client ne conservent pas les informations actuelles sur la session utilisateur. Le client et le serveur peuvent utiliser une forme de jeton pour assurer l'authentification entre les demandes, mais aucune autre information actuelle n'est stockée. Un cas d'utilisation typique pour une telle solution pourrait être un site de nouvelles où la plupart des utilisateurs (nouveaux consommateurs) consomment des informations sans produire d'informations renvoyant au site. Dans ce cas, le site n'a pas besoin de conserver d'informations sur la session utilisateur en cours. Notez que le site peut toujours utiliser des cookies pour identifier l'utilisateur et stocker des informations sur l'utilisation du site par cet utilisateur, mais cela peut toujours être considéré comme sans état, dans la mesure où tout ce qui est enregistré peut être transactionnel, par exemple le lien sur lequel l'utilisateur a cliqué, qui pourrait être enregistré par le serveur, mais pas maintenu dans une session d'utilisateur.
Statefulness sur le serveur
Sur le serveur, une application avec état enregistre les informations d'état concernant les utilisateurs actuels. Cette approche implique généralement l'utilisation de cookies pour identifier le système de l'utilisateur afin que cet état puisse être maintenu sur le serveur entre les demandes. Les sessions peuvent ou non être authentifiées, en fonction du contexte de l'application. Les applications de serveur avec état offrent l'avantage de mettre en cache les informations d'état de l'utilisateur sur le serveur, d'accélérer les recherches et le temps de réponse des pages. Inconvénient, stocker des informations dans l'étendue de la session coûte cher et, à grande échelle, cela nécessite beaucoup de ressources. Il crée également un vecteur d’attaque potentiel permettant aux pirates d’essayer de détourner les identifiants de session et de voler les sessions utilisateur. Les applications de serveur avec état ont également pour défi de protéger les sessions utilisateur contre les interruptions de service inattendues, telles que les pannes de serveur.
Statefulness sur le client
À l'aide de JavaScript et de technologies de navigation modernes telles que sessionStorage, les applications peuvent désormais stocker facilement des informations sur l'état d'une session utilisateur sur le périphérique de cet utilisateur. Dans l’ensemble, l’application peut toujours être considérée comme un état, mais le travail de maintien de l’état a été déplacé vers le client. Cette approche présente un gros avantage (pour le responsable de l'application Web) par rapport au maintien de l'état sur le serveur, dans la mesure où chaque utilisateur maintient son propre état et que l'infrastructure du serveur n'est pas surchargée. À l'échelle du Web, ce type de choix architectural a d'énormes répercussions sur les coûts de matériel et d'électricité. Le maintien de l'état sur le serveur pourrait coûter des millions de dollars par an. Passer à un système maintenant le système sur le client pourrait alors économiser des millions de dollars par an.
Jetons v. Cookies
Les cookies agissent comme des identifiants pour les appareils clients / navigateurs. Ils peuvent être utilisés pour stocker toutes sortes de choses, mais généralement, ils stockent une forme d'identifiant, comme CFID / CFTOKEN dans les applications CFML. Les cookies peuvent être configurés pour vivre longtemps dans le navigateur de l'utilisateur, ce qui permet par exemple de maintenir l'authentification sur une application entre les sessions du navigateur. Les cookies peuvent également être configurés uniquement en mémoire afin qu'ils expirent lorsqu'un utilisateur ferme le navigateur.
Les jetons sont généralement une sorte d'informations d'identification sur l'utilisateur générées sur le serveur (en utilisant un cryptage pour brouiller les informations), transmises au client et renvoyées au serveur avec la requête suivante. Ils peuvent être transmis dans l'en-tête de la demande et de la réponse, ce qui est un modèle courant dans les applications à page unique. Idéalement, chaque requête / réponse génère un nouveau jeton. Par conséquent, les jetons ne peuvent pas être interceptés et utilisés plus tard par un attaquant.
Applications sur une seule page et état du client
Avec les SPA, les informations d'état sont chargées dans le navigateur client et y sont conservées. Lorsque l'état change, par exemple si vous publiez une mise à jour sur votre compte de réseau social, le client relaie cette nouvelle transaction sur le serveur. Dans ce cas, le serveur enregistre cette mise à jour dans un magasin de données persistant, comme une base de données, et retransmet au client les informations dont il a besoin pour se synchroniser avec le serveur en fonction de la mise à jour (par exemple, un ID pour la mise à jour).
Notez que ce modèle d'état de stockage sur le client offre des avantages pour les expériences en ligne / hors ligne dans la mesure où vous pouvez être déconnecté du serveur tout en conservant une application quelque peu utilisable. Twitter est un bon exemple de ce cas, où vous pouvez consulter tout ce qui est chargé côté client dans votre flux Twitter, même si vous êtes déconnecté de l'application du serveur Twitter. Ce modèle crée également une complexité dans la synchronisation entre serveur et client, qui est un sujet à part entière. Les complexités de la solution sont un compromis pour pouvoir maintenir l’état sur le client.
L'état d'état sur le client permet aux applications Web de se sentir et de se comporter davantage comme les applications de bureau traditionnelles. Contrairement aux applications de bureau, toutes les informations de votre compte ne seront généralement pas chargées dans votre session client dans un navigateur. Dans de nombreux cas, cela serait irréalisable et produirait de mauvaises expériences. Pouvez-vous imaginer essayer de charger une boîte Gmail entière dans le navigateur? Au lieu de cela, le client conserve des informations telles que l'étiquette / le dossier que vous consultez et l'emplacement de la liste des courriels de ce dossier que vous recherchez. Équilibrer quelles informations d'état à conserver et que demander selon les besoins est un autre défi technique de ce modèle. Encore une fois, cela représente un compromis entre l'aspect pratique et la fourniture d'une bonne expérience utilisateur.
Chariots de magasinage et similaires
En ce qui concerne les spécificités telles que les paniers d'achat, cela dépend vraiment de la solution. Un panier peut être stocké dans une base de données sur le serveur, il peut être stocké uniquement dans la portée de session sur le serveur ou même dans le client. Amazon propose des paniers d'achat permanents pour les utilisateurs connectés et des paniers "temporaires" pour les utilisateurs anonymes, bien que ces paniers soient persistants dans une certaine mesure.
Lorsque vous parlez de Google, par exemple, qui regroupe différentes applications de la même marque, elles ne partagent probablement pas une architecture commune et chacune est conçue de manière à répondre au mieux aux besoins de ses utilisateurs. Si vous souhaitez savoir comment un site est construit, ouvrez les outils de développement de votre navigateur et consultez-le. Recherchez des cookies, surveillez le trafic réseau et voyez comment il fonctionne.
Désolé si cette réponse décale un peu, mais l'état d'esprit est un sujet complexe.
la source
Les sessions et les cookies ne doivent pas être évités. Vous pouvez toujours les avoir avec des applications Web sans état.
Il y a une grande différence entre Java et Ruby on Rails. Les applications Java vont stocker la session en mémoire en utilisant une clé de session stockée dans un cookie. Cette procédure est rapide pour récupérer l’état de l’utilisateur et le panier. Cependant, vous devez toujours utiliser le même serveur avec votre session.
Les applications Rails stockent l'identifiant de l'utilisateur dans un cookie crypté et signé. Il ne peut pas être altéré. Lorsque vous chargez une page, l'application Web récupère votre état, votre utilisateur et votre panier d'achat à partir d'une base de données. C'est plus lent, mais l'essentiel est que vous puissiez frapper n'importe quel cas ! Cela vous permet de redémarrer, d’échelonner et d’arrêter les instances à volonté. Très pratique. Il peut également être rendu plus rapide avec une base de données cache partagée en mémoire, telle que Redis. Vous pouvez également stocker le panier dans le cookie, à condition qu'il soit suffisamment petit.
Vous pouvez ainsi atteindre l'apatridie, grâce à des techniques intelligentes, et ajouter la possibilité d'évoluer à votre guise.
la source
Le protocole est apatride.
Mais à partir de là, il ne s'ensuit pas nécessairement que les applications utilisant le protocole doivent être sans état.
Voici quelques réponses StackOverflow associées qui expliquent bien la différence:
la source
Lorsque vous faites référence à stateless, par exemple dans un service HTTP RESTful, vous évitez de stocker l’état du côté serveur. Au mieux, cela implique également d'éviter de stocker tout état dans une base de données ou dans d'autres stockages persistants sur le backend. Pour que ce soit clair, je parle d'un état et non de données en général. Il semble que certains gars mélangent les choses.
Une communication sans état présente plusieurs avantages, notamment en ce qui concerne l'évolutivité et la disponibilité.
C'est vrai (pour certains protocoles d'authentification et d'autorisation). Les jetons peuvent (mais non en tant que tels) fournir toutes les informations contenues dans la demande qui sont nécessaires pour authentifier un utilisateur ou autoriser une action. Pour un exemple, jetez un oeil à JWT .
Concernant l'exemple du panier d'achat. Ce n'est pas un problème de stocker tous les éléments du panier côté client sans utiliser de session ou de cookies. Vous pouvez trouver un exemple sur smashingmagazine.com . Mais il est également possible de créer un panier d'achat sans état avec des cookies (du moins si votre assortiment n'est pas si grand et qu'un stockage de 4 ko est suffisant pour vous).
Ne vous méprenez pas, cela ne signifie pas que vous deviez mettre en place un panier d'achat apatride à tout prix. Amazon ou d’autres grandes plates-formes de vente en ligne utilisent des implémentations de panier dynamiques, car l’expérience et la convivialité des utilisateurs sont plus importantes pour elles que la satisfaction d’exigences techniques non fonctionnelles telles que l’évolutivité.
En règle générale, les jetons ne sont pas utilisés pour stocker des informations telles que des éléments de panier. Ils sont utilisés pour une authentification et une autorisation sans état.
Si vous leur demandez s'ils utilisent des cookies ou des jetons pour l'authentification, la réponse est qu'ils utilisent les deux. Les utilisateurs utilisent principalement des cookies pour les clients techniques.
la source
OK, la règle que vous citez est techniquement incorrecte. Toutes les couches d'une application Web ont un état.
Le but de la règle est "ne conservez pas le côté serveur par session".
C'est-à-dire les variables de session dans ASP , qui étaient couramment utilisées pour faire des choses comme des éléments dans le panier / nom d'utilisateur, etc.
La raison est que vous manquerez de mémoire sur le serveur à mesure que votre application gagnera plus d'utilisateurs. Déplacer le stockage vers une base de données ou un cache partagé ne résout pas le problème car vous avez toujours un goulot d'étranglement.
Pour conserver l'état d'application par utilisateur sans rencontrer ce problème, déplacez l'état vers le côté client. Par exemple, placez les éléments du panier dans un cookie ou dans un stockage plus avancé côté client.
Étant donné que le nombre de clients augmente avec le nombre d'utilisateurs, votre application dans son ensemble n'aura pas de goulot d'étranglement et évoluera bien.
la source