2009-09-08 9 views
4

Nous avons une page de confirmation d'email pour l'enregistrement qui peut être frappé avec un lien d'utilisation unique pour activer le compte.Asp.net Mvc FormsAuth avec LogonUserControl dans Site.Master

La nature du site est telle que nous pouvons autoriser ce lien à se connecter automatiquement à l'utilisateur. Cette exigence est en cours de révision (à ma demande!).

La situation suivante se révèle un peu déroutant:

  1. L'utilisateur suit le lien de confirmation dans leur email
  2. ces terres sur le contrôleur de confirmation.
  3. Toutes choses bien, l'utilisateur est automatiquement connecté, en utilisant:

    FormsAuth.SignIn(user.UserName,false); 
    
  4. La vue est renvoyée par le contrôleur

La vue utilise une page maître qui contient une partie Vue qui est le composant LogonUserControl.ascx. Dans le composant, il y a le code suivant (il sort directement du modèle de projet asp.net mvc):

if (Request.IsAuthenticated) { /*foo*/ } 

Lorsque la page est affichée, Request.IsAuthenticated est soit faux, malgré la signature de l'utilisateur au contrôleur .

Je me demande pourquoi cela pourrait être. Le maître a-t-il déjà été écrit au moment de l'appel de la méthode FormsAuth.SignIn ou utilise-t-il incorrectement l'objet Demande pour cette vérification, car au moment de la réception de la demande, il était effectivement non authentifié?

EDIT: Il semble que le contrôleur LogOn par défaut utilise une redirection au lieu de renvoyer une vue. Cela permettrait bien sûr de résoudre le problème, mais je m'intéresse à la raison pour laquelle le scénario ci-dessus ne fonctionne pas.

Répondre

3

Cela ne fonctionne pas car la demande, qui s'est déjà produite avant l'exécution de votre action, n'a pas été authentifiée. Une demande est soit authentifiée, soit elle ne l'est pas; il ne peut pas commencer sa vie comme non authentifié et s'authentifier au milieu d'une action. Une demande authentifiée est une requête qui a été soumise avec un ticket d'authentification valide. Puisque la demande de connexion ne l'inclut pas, elle n'est pas authentifiée et ne peut pas être authentifiée.

Cependant, lorsque vous redirigez, le navigateur émet une nouvelle requête, qui, bien sûr, vient avec un ticket d'authentification valide, généralement sous la forme d'un cookie. Par ailleurs, la redirection est la bonne chose à faire dans ce cas. Votre connexion est un POST, et vous devez utiliser le modèle Post/Redirect/Get. Imaginez que la page de connexion renvoie l'utilisateur à la page d'accueil du site. Si vous renvoyez la vue au lieu de la rediriger vers la page d'accueil, lorsque l'utilisateur appuie sur F5 pour actualiser la page, le navigateur l'avertit qu'il est sur le point de renvoyer ses informations de connexion, ce qui n'est pas le cas. Faire une redirection fait que le navigateur fasse un GET pour la page d'accueil, ainsi l'utilisateur ne sera pas averti s'il appuie sur F5.

+1

Grande explication, a couru il y a quelque temps, n'a jamais compris pourquoi, maintenant je le fais. – mxmissile

Questions connexes