comparaison des moyens de maintenir l'état

Question

Il existe différentes manières de conserver l'état utilisateur en utilisant le développement Web.

Ce sont ceux auxquels je peux penser en ce moment:

1. Chaîne de requête

2. Cookies

3. Méthodes de formulaire (Obtenir et publier)

4. Viewstate (ASP.NET seulement, je suppose)

5. Session (serveur Web InProc)

6. Session (serveur Web dédié)

7. Session (base de données)

8. Persistance locale (Google Gears) (merci Steve Moyer) etc.

Je sais que chaque méthode a ses avantages et ses inconvénients, tels que les cookies qui ne sont pas sécurisés et QueryString ayant une limite de longueur et qui sont vraiment laids à regarder! ;)

Cependant, lors de la conception d'une application Web, je suis toujours confus quant aux méthodes à utiliser pour quelle application ou aux méthodes à éviter.

Ce que j'aimerais savoir, c'est quelle (s) méthode (s) utilisez-vous généralement et recommanderiez ou, plus intéressant encore, laquelle de ces méthodes souhaitez-vous éviter dans certains scénarios et pourquoi?

Answer 1

Même s’il est très difficile de répondre à cette question, j’ai quelques petites remarques à faire lorsque je pense à la mise en œuvre de l’état.

• L’état de la chaîne de requête n’est utile que pour les tâches les plus élémentaires - maintien de la position d’un utilisateur dans un assistant, par exemple, ou création d’un chemin vers lequel rediriger l’utilisateur après l’achèvement d’une tâche donnée (par exemple, connexion ). Sinon, l'état de la chaîne de requête est terriblement peu sûr, difficile à mettre en œuvre et, pour le rendre juste, il doit être lié à une machine d'état côté serveur en contenant une clé pour lier le client à l'état maintenu du serveur pour ce client.
• L'état du cookie est plus ou moins le même - il est juste plus sophistiqué que l'état de la chaîne de requête. Mais il reste totalement maintenu côté client, sauf si les données du cookie sont une clé pour lier le client à une machine d'état côté serveur.
• L’état de la méthode de formulaire est à nouveau similaire: c’est utile pour masquer les champs qui lient un formulaire donné à un bit de données à l’arrière (par exemple, "cet utilisateur est en train de modifier l’enregistrement n ° 512, le formulaire contiendra donc un masque entrée avec la valeur 512 "). Ce n'est pas utile pour beaucoup d'autres choses, et encore une fois, ce n'est qu'une autre implémentation de la même idée derrière la chaîne de requête et l'état du cookie.
• Les états de session (quels que soient les moyens que vous décrivez) sont excellents, car ils sont extensibles à l'infini et peuvent gérer tout ce que votre langage de programmation peut gérer. Le premier inconvénient est qu'il doit y avoir une clé dans la main du client pour lier ce client à son état stocké sur le serveur; C'est ici que la plupart des infrastructures Web fournissent au client une clé basée sur un cookie ou une chaîne de requête. (Presque tous les modernes utilisent des cookies, mais retombent sur les chaînes de requête si les cookies ne sont pas activés.) La deuxième mise en garde est que vous devez en ajouter dans la façon dont vous stockez votre état. base de données? Est-ce que votre framework web le gère entièrement pour vous? Encore une fois, la plupart des frameworks Web modernes en prennent le travail, et pour pouvoir implémenter ma propre machine d'état, j'ai besoin d'une très bonne raison ... sinon, je risque de créer une sécurité. les ruptures et les ruptures de fonctionnalités qui ont été hachées au fil du temps dans n’importe quel cadre mature.

Je suppose donc que je ne peux vraiment pas imaginer ne pas vouloir utiliser l'état basé sur la session pour autre chose que la raison la plus triviale.

Answer 2

La sécurité est également un problème. les valeurs de la chaîne de requête ou des champs de formulaire peuvent être modifiées de manière triviale par l'utilisateur. L'authentification de l'utilisateur doit être enregistrée dans un cookie crypté ou inviolable, ou dans une session côté serveur. Le suivi des valeurs transmises dans un formulaire en tant qu’utilisateur complète un processus, comme une inscription de site, qui peut probablement être conservé dans des champs de formulaire masqués.

La chose intéressante (et parfois dangereuse) sur la chaîne de requête est que l’état peut être détecté par toute personne qui clique sur un lien. Comme mentionné ci-dessus, ceci est dangereux s'il donne à l'utilisateur une autorisation qu'il ne devrait pas avoir. C'est bien de montrer à vos amis quelque chose que vous avez trouvé sur le site.

Answer 3

Avec l'utilisation croissante du Web 2.0, je pense qu'il manque deux méthodes importantes dans votre liste:

8 applications AJAX - puisque la page ne se recharge pas et qu'il n'y a pas de navigation entre les pages, l'état n'est pas un problème (mais les données utilisateur persistantes doivent utiliser les appels XML asynchrones).

9 Persistance locale: les applications basées sur un navigateur peuvent conserver leurs données utilisateur et leur état sur le disque dur local à l'aide de bibliothèques telles que Google Gears.

En ce qui concerne le meilleur choix, je pense qu'ils ont tous leur place, mais la méthode Query String pose problème aux moteurs de recherche.

Answer 4

Personnellement, comme presque tout mon développement Web est en PHP, j'utilise les gestionnaires de session PHP.

D'après mon expérience, les sessions sont les plus flexibles: elles sont normalement plus rapides que les accès à la base de données et les cookies qu'elles génèrent meurent à la fermeture du navigateur (par défaut).

Answer 5

Évitez InProc si vous envisagez d’héberger votre site Web sur un hôte bon marché, comme Webhost4life. J'ai appris à leurs dépens que, parce que leurs systèmes sont surabonnés, ils recyclent les applications très fréquemment, ce qui entraîne la perte de votre session. Très ennuyant.

Leur suggestion est d’utiliser StateServer, ce qui est bien, sauf que vous devez sérialiser / désérialiser la session après la publication. J'adore les objets et mon application Web en est pleine. Je suis préoccupé par les performances lors du passage à StateServer. J'ai besoin de refactoriser pour ne mettre que les choses dont j'ai vraiment besoin dans la session.

Je voudrais le savoir avant de commencer ...

Cordialement, Rob.

Answer 6

Faites attention à l'état dans lequel vous stockez le côté client (chaînes de requête, champs de formulaire, cookies). Tout ce qui concerne la sécurité ne devrait pas être stocké côté client, sauf peut-être un identifiant de session s'il est raisonnablement masqué et difficile à deviner. Trop de sites Web ont des paramètres tels que " authentifié = true " et les stocker dans un cookie, une chaîne de requête ou un champ de formulaire masqué. Il est trivial pour un utilisateur de contourner quelque chose comme ça. N'oubliez pas que TOUTE entrée provenant d'un client aurait pu être falsifiée et ne devrait pas être approuvée.

Answer 7

Cookies signés liés à une sorte de magasin de base de données lorsque vous devez vous en procurer Les données. Il n’ya aucune raison de stocker des données côté client si vous avez un back-end connecté; vous êtes simplement à la recherche de problèmes s'il s'agit d'un site Web public.

Answer 8

Ce n’est pas vraiment une question de savoir quoi utiliser & amp; Ce qu'il faut éviter, mais quand utiliser lequel. Chacun a des circonstances particulières quand c’est le meilleur et des circonstances différentes quand c’est le pire.

Le facteur décisif est généralement la durée de vie des données. L'état de la session vit plus longtemps que les champs de formulaire, etc.