En travaillant avec l'authentification par formulaires ASP.Net, je suis tombé sur le cookie .ASPXAUTH. J'ai quelques questions:
Le cookie ASPXAUTH est utilisé pour déterminer si un utilisateur est authentifié.
En ce qui concerne l'emplacement du cookie, cela dépend de votre navigateur. Si vous utilisez Firefox, vous pouvez afficher le cookie en cliquant sur Outils -> Options -> Confidentialité. Ensuite, faites défiler jusqu'au domaine et développez-le pour voir le cookie et sa valeur. La valeur est chiffrée à l'aide de la clé machine (située dans le fichier machine.config ou web.config du serveur). Par conséquent, le cookie sur le client ne vous fournira pas vraiment d'informations. Vous pouvez décrypter/afficher la valeur côté serveur en utilisant:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
où authTicket
a ces champs:
L'instruction "ASPXAUTH est fondamentalement utilisée pour conserver l'état de session ASP.NET" est incorrecte. ASP.NET émet un cookie totalement différent, nommé ASP.NET_SessionId, pour suivre l'état de la session.
En réalité, le cookie .ASPXAUTH ne vous dit pas exactement quand l'utilisateur est authentifié. Lorsque l'utilisateur se déconnecte de l'application, le cookie .ASPXAUTH est supprimé du navigateur. Toutefois, si vous revenez sur le site dans un court laps de temps (avec expiration du cookie d'authentification de formulaire) et modifiez le nouveau cookie ASP.NET_SessionId avec les éléments suivants:
Après l'actualisation, vous pourrez assumer l'identité de l'utilisateur authentifié sans nouvelle authentification technique. (encore une fois en supposant que vous le fassiez dans le délai d'attente spécifié dans la chaîne d'authentification cryptée .ASPXAUTH)
Un bon blog post explique le problème plus en détail. Une solution possible consiste à coupler le fichier .ASPXAUTH à la session ASP.
Si les interactions d'un utilisateur avec l'URL de connexion HTML ont permis au TSWPPserver d'établir l'identité de l'utilisateur, le serveur distant DEVRAIT générer un cookie qui identifie l'utilisateur et permet l'authentification sur le serveur. Le contenu du cookie DEVRAIT être signé et crypté. L'implémentation spécifique de ce cookie, y compris les algorithmes de signature et de cryptage, dépend de l'implémentation du serveur TSWPP, car seul le serveur est requis pour analyser le contenu du cookie. Si le serveur implémente le cookie, celui-ci DOIT alors être renvoyé dans une charge HTTP avec un type de contenu de type "application/x-msts-webfeed-login".