J'essaie de comprendre comment ASP.NET valide en interne qu'un cookie permettra à l'utilisateur d'accéder à l'application. CookieAuthenticationMiddleware définira .AspNet.Cookies avec une valeur cryptée. Après .NET déchiffre le cookie avec succès sur une demande, quelle validation se produit alors? Développer localement avec IISExpress si j'ai une application (# 1) qui définit un cookie d'authentification après que l'utilisateur se connecte, et que je crée une nouvelle application complète (# 2) fonctionnant également sur localhost, qui utilise aussi CookieAuthentication. Quand j'accède # 2 il lira le cookie du # 1 et permet à l'utilisateur d'accéder à l'application aussi bien. J'essaie de comprendre quelles sont les limites de l'authentification par cookie.Comment un cookie est-il validé en interne par ASP.NET MVC en utilisant CookieAuthenticationMiddleware?
Répondre
Il n'y a pas vraiment de "validation" en soi. La clé cryptée du cookie est utilisée pour référencer l'utilisateur qui doit être "connecté". Il fonctionne de manière très similaire aux sessions, où le cookie de session contient un identifiant de session crypté que le serveur peut utiliser pour rechercher et restaurer la session via.
Le chiffrement/déchiffrement est basé sur la clé machine, qui peut être explicitement définie dans Web.config ou générée automatiquement par ASP.NET. Seules les applications partageant la même clé d'ordinateur peuvent déchiffrer le cookie. C'est pourquoi il est si important de protéger votre clé machine.
De toute façon, il y a deux facteurs impliqués ici. Tout d'abord, les cookies sont liés au domaine: seuls les domaines ou sous-domaines du domaine sur lesquels le cookie est activé recevront le cookie. Ceci est géré par le client (c'est-à-dire le navigateur). Vos deux applications sont actuellement en mesure de voir le cookie car elles s'exécutent toutes deux sur localhost. Cependant, si vous deviez en déployer un sur foo.com et l'autre sur bar.com, ils ne pourraient plus voir les cookies les uns des autres. Deuxièmement, la clé de la machine est généralement fournie par le serveur (sauf si vous l'avez explicitement définie dans Web.config par application). Par conséquent, les sites qui s'exécutent sur la même machine peuvent généralement déchiffrer les cookies les uns des autres (en supposant qu'ils les voient en premier lieu, ce qui, encore une fois, est basé sur leur domaine).
On ne sait pas si vous êtes satisfait ou pas de cet arrangement. Si votre objectif est de séparer les deux sites s'exécutant localement, de sorte qu'ils ne partagent pas de cookies, vous disposez de plusieurs options.
Vous pouvez définir explicitement une clé différente de la machine pour chaque site dans leurs fichiers Web.config respectifs. Ils recevront toujours les cookies définis par l'autre site, mais ils ne seront plus en mesure de les déchiffrer, ce qui entraînera leur ignorance.
Vous pouvez personnaliser le nom du cookie d'authentification. Au lieu d'utiliser le nom de cookie par défaut, vous pouvez en créer un
.Site1.Authet l'autre.Site2.Auth.Ensuite, même si l'un ou l'autre des sites recevra également le cookie de l'autre site, il l'ignorera simplement, car il ne s'agit pas du cookie d'authentification.
Si, cependant, vous avez l'intention de compter sur ce comportement dans la production aussi bien (vous voulez réellement exploitation forestière dans un site pour vous connecter à l'autre aussi bien), alors vous aurez besoin pour définir explicitement la clé de la machine à la même valeur dans les deux fichiers Web.config du site. De plus, vous devrez les déployer sur le même domaine, ou au moins sur les sous-domaines de ce domaine. Dans le cas des sous-domaines, vous devez définir le domaine de cookie comme étant le domaine générique .mydomain.com pour les deux. Ensuite, vous pourriez en avoir un au foo.mydomain.com et un autre au bar.mydomain.com, et ils verront tous les deux le cookie parce qu'il a été réglé sur .mydomain.com. Si vous laissez la valeur par défaut, définie sur le domaine réel du site, alors bar.mydomain.com ne pouvait pas voir un cookie défini par foo.mydomain.com car ce cookie ne serait explicitement défini que pour foo.mydomain.com.
Les principales validations sont le cryptage et l'expiration. Si les applications partagent un contexte de chiffrement (par exemple, une clé machine), elles peuvent partager des cookies d'authentification (en fournissant d'autres règles de partage côté client telles que les domaines et les chemins d'accès). Alors oui, il est prévu que deux applications utilisant IIS Express localhost sur la même machine partagent les cookies par défaut.
La date d'expiration est également intégrée dans la valeur cryptée afin que le client ne puisse pas la modifier.
Merci pour la réponse élaborée. – AlejandroC