Création d'un site Web ASP.Net MVC évolutif sans utiliser la session

Question

Je travaille sur un projet Web utilisant Asp.Net MVC, que je devrai déployer dans un environnement de batterie de serveurs. J'ai lu beaucoup d'articles et je pense à désactiver complètement le SessionState, je pense que cela ferait une application plus robuste, et me sauvera quelques maux de tête (Tout ce que j'ai lu me dit que gérer des sessions sur une ferme n'est pas trivial).

Il y a certaines choses que je n'ai toujours pas totalement claires avec cette approche, la principale étant le processus d'authentification/d'autorisation. Fondamentalement, je ne suis pas sûr de comment (si?) Je peux gérer les sessions utilisateur si aucun SessionState n'est activé sur le serveur. Si un utilisateur se connecte au site Web et essaie ensuite d'accéder à une autre page, comment puis-je savoir que l'utilisateur est déjà connecté? Je sais que l'utilisation de cookies n'est pas sûre, j'ai pensé à un mélange de cookies avec l'identifiant de session stocké dans la BD, mais je suppose que si je désactive SessionState, je n'aurai pas non plus accès à l'ID de session.

Quelle est la meilleure approche à ce sujet? Y a-t-il un livre/article recommandé que vous pouvez me montrer afin que je puisse le comprendre?

Merci beaucoup pour votre aide

Answer 1

Je pense que l'utilisation d'authentification par formulaire pour ce que ce sera gérer votre connecté nom d'utilisateur et vous pouvez également l'autorisation mis en travers.

http://msdn.microsoft.com/en-us/library/ff647070.aspx

http://msdn.microsoft.com/en-us/library/xdt4thhy.aspx

http://www.codeproject.com/KB/web-security/formsroleauth.aspx

http://www.beansoftware.com/ASP.NET-Tutorials/Forms-Authentication-Active-Directory.aspx

Ces liens sont de votre ans chaque question. Grâce à cela, vous pouvez gérer l'autorisation de rôle et la session

Answer 2

Il se peut qu'il soit possible que des processus que votre application prend en charge et que vous souhaitez conserver au cours du recyclage de l'application (défaillance du nœud de cluster) puissent ignorer complètement les complexités de session persistantes. . Considérons un exemple de paiement par e-commerce ou un processus multi-étapes similaire qui nécessite une gestion importante de l'état avant la fin. La suggestion est de concevoir le model de votre application de manière à ce que pendant ces "étapes" la progression de l'ouvrage soit conservée nativement dans le magasin de données via le modèle. Autrement dit, le "workfolow" n'est pas une sorte d'externalité au modèle principal de votre application et est traité comme une chose "temporaire" qui nécessite un mécanisme de persistance comme la session aspnet par opposition au magasin de données régulier des applications (base de données) . Par exemple, plutôt que de stocker l'arborescence d'objets checkout (listes d'éléments, de commandes, etc.) dans Session, persistez dans la base de données elle-même. De cette façon, non seulement cette "validation partiellement terminée" survit à la défaillance du nœud ou au recyclage de l'application, mais si cet utilisateur doit éteindre un feu urgent dans la cuisine ou que Windows Update bloque son PC, il peut le reprendre dès qu'il se connecte. . : D Et: vous évitez tout ce truc complexe de gestion de session distribuée. Yuk! Je sais que cette réponse va bien au-delà du point d'authentification mis en évidence par la question, mais il est bon de savoir et certainement un problème que posent les environnements groupés/fermiers sur les applications aspnet.

Hanselman sur les applications mvc en cluster: http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx

Answer 3

FormsAuthentication et le travail de profil utilisateur ASP.NET sans SessionState activées - ils courent sur les cookies et la base de données par les recherches par défaut. Pour les scénarios de type panier, il est fortement recommandé d'enregistrer les données dans la base de données et d'étiqueter les utilisateurs. Cela permet aux utilisateurs de revenir et de récupérer des paniers abandonnés.

Ce qui peut et va se casser sans que SessionState ne soit activé est TempData de MVC - il stocke des choses dans la session entre les pages. Mais, si vous évitez juste de l'utiliser, vous êtes en or.