Comment ASP.NET (ou tout cadre Web) implémente-t-il l'état de session persistante?

Question

Pour diverses raisons, j'en ai marre de l'état de la session ASP.NET et j'essaie de le faire moi-même (question séparée bientôt liée à pourquoi je suis marre et si c'est faisable de le faire moi-même, mais pour l'instant nous allons supposons que c'est). Les problèmes de sécurité mis à part, il semble que les sessions de suivi impliquent un peu plus que de stocker un cookie avec un guid et d'associer ce guid à une petite table de "sessions" dans la base de données contenant un petit nombre de champs pour suivre le délai et pour lier à la clé primaire dans la table de l'utilisateur, pour les sessions qui sont liées aux utilisateurs enregistrés.

Mais je suis bloqué sur un détail avec le cookie, dans le cas où le navigateur de l'utilisateur n'est pas configuré pour accepter les cookies. Il me semble que chaque fois qu'un utilisateur accède à une page dont l'état de session est activé, ASP.NET doit déterminer si le navigateur supporte les cookies. Si un cookie de session est déjà envoyé avec la demande, il est évident que les cookies sont acceptés. Si ce n'est pas le cas, il semble qu'il a besoin de vérifier, ce qui, comme je le comprends, consiste à essayer d'écrire un cookie et de rediriger vers une page qui essaie de lire le cookie. Il semble donc, lorsqu'un utilisateur avec les cookies mis plusieurs visites de pages d'un site, que ASP.NET

(a) doit faire ce test aller-retour pour chaque page que l'utilisateur visite ou

(b) doit supposer que le navigateur accepte les cookies et créer un enregistrement avec un identifiant de session (provisoire) pour l'utilisateur sur chaque page - et si l'état de la session est censé être persistant, il semble qu'il doit écrire cet identifiant de session base de données sur chaque page.

Mais (a) semble fou et (b) semble fou aussi, puisque nous accumulerions rapidement des identifiants de session pour toutes ces sessions d'une seule page. Donc je pense qu'il doit y avoir une autre astuce/heuristique qui est utilisée pour savoir quand faire le test aller-retour et/ou quand créer un enregistrement pour la session.

Ai-je tort d'être perplexe?

(Pour être clair, je ne parle pas d'implémenter une solution de stockage personnalisée dans le système d'état de session enfichable d'ASP.NET.Je parle de sauter complètement le système d'état de session d'ASP.NET Ma question est une version plus détaillée de celui-ci: Implementing own Session Management in ASP.NET.)

Answer 1

Eh bien, les cookies sont un mécanisme standard d'authentification Web. Avez-vous une raison quelconque pour laquelle vous ne voudriez pas les utiliser? Êtes-vous sûr de ne pas essayer d'inventer un problème là où il n'y a pas de problème?

Les sites Web les plus graves que je connais exigent que le navigateur accepte les témoins pour que l'utilisateur soit authentifié. Il est sûr de supposer que chaque navigateur moderne les prend en charge.

Il y a un article intéressant sur cookieless ASP.NET que vous devriez lire.

EDIT:

@ o.k.w: Par défaut, l'état de session est conservé par ASP.NET en cours (lire: en mémoire). Sauf indication explicite de la part de la configuration de stocker la session dans la base de données (SQL Server est pris en charge immédiatement), cela n'entraînera pas d'échec de la base de données. Les états de session périmés seront purgés du stockage en cours de traitement. Malheureusement, avec les paramètres ASP.NET par défaut, chaque requête sans cook entraînera la création d'une nouvelle session.

Voici une comparaison détaillée des options de stockage de session disponibles: http://msdn.microsoft.com/en-us/library/ms178586.aspx.

Answer 2

Le comportement de session est défini via l'élément sessionState dans web.config. Dans l'élément sessionState, le HttpCookieMode peut être défini sur UseUri, UseCookies, AutoDetect, UseDeviceProfile. UseUri et UseCookies indiquent explicitement à ASP.NET comment gérer le stockage de l'identificateur de session.

Si UseDeviceProfile est utilisé, le comportement est déterminé par le fait que l'agent utilisateur prend en charge les cookies (pas qu'ils soient activés ou non).

AutoDetect est le cas intéressant qui vous intéresse. La manière dont ASP.NET gère la détection automatique est expliquée dans Understand How the ASP.NET Cookieless Feature Works. Dans cet article, vous verrez qu'ils ont 5 contrôles différents qu'ils font. L'une des vérifications est, comme vous le mentionnez, de définir un cookie et de faire une redirection pour voir si le cookie existe. Si le cookie existe, le navigateur prend en charge les cookies et le cookie sessionID est défini. Cependant, ceci n'est pas fait à chaque requête car une autre vérification avant de lancer la redirection est de vérifier l'existence de cookies. Puisque après le cookie set-initial et la redirection, le cookie sessionID sera défini, l'existence du cookie permet à ASP.NET de savoir que les cookies sont supportés et qu'aucun autre set-cookie et aucune redirection ne sont nécessaires.