2009-11-18 8 views
1

Voici le scénario: lorsqu'un nouvel utilisateur s'enregistre sur notre site Web, nous voulons envoyer un e-mail pour vérifier que l'utilisateur possède l'adresse e-mail. Dans le courriel il y a un lien vers une page qui fera la vérification, quelque chose comme ceci:ASP.NET MVC: Utiliser GET et POST dans la même méthode

http://www.mysite.com/account/verify/token

La méthode verify ressemble à ceci:

[AcceptVerbs(HttpVerbs.Get)] 
public ActionResult Verify(Nullable<Guid> id) 
{ 
    // tries to get the user based on the verification code 
    if (ValidId(id)) 
    { 
     // if the id is correct, update user data in the model and redirect 
     return RedirectToAction("Index", "Dashboard"); 
    } 
    else 
    { 
     // redirects the user to the verify view 
     return View("Verify"); 
    } 
} 

La vue « Vérifier » est tout simplement un zone de texte avec un bouton, de sorte que l'utilisateur peut entrer le code de vérification manuellement (l'utilisateur peut accéder à cette page à partir du site, et pourrait préférer simplement copier-coller le code). Lorsque l'utilisateur clique sur le bouton, je veux faire la même chose que ma méthode GET; donc j'ai fini avec quelque chose comme ceci:

[AcceptVerbs(HttpVerbs.Get | HttpVerbs.Post)] 
public ActionResult Verify(Nullable<Guid> id) { ... } 

J'ai quelques problèmes avec ce code (qui fonctionne, mais ...):

  • Est-il acceptable d'avoir un GET et POST méthode? Ou y a-t-il une meilleure façon de gérer ce scénario?
  • Je modifie les données dans une méthode GET (si l'id est correct, je mets à jour les données de l'utilisateur pour refléter que c'est vérifié) et c'est un gros NON NON ... encore, je veux que l'utilisateur puisse juste cliquez sur le lien et vérifiez le jeton. Y a-t-il un meilleur moyen d'y parvenir?

Merci

+0

La vue __Verrify__ peut recevoir une requête du formulaire en utilisant JS, vous n'aurez donc pas d'action séparée. Non? – Amirshk

Répondre

1

Personnellement, je ne voudrais pas déranger avec l'attribut AcceptVerbs. (** Voir la note ci-dessous) Vous pourriez alors combiner ceci en une action, qui pourrait répondre au besoin. (Je montre un code non testé ci-dessous.) La raison pour laquelle j'ajoute une réponse au lieu d'un commentaire est que je voulais vous recommander d'ajouter une branche à votre logique, pour gérer un code qui a échoué (pour présenter un message d'erreur) .Vous pouvez bien sûr afficher <%=ViewData["message"]%> dans votre vue Vérifier. Ceci est bien sûr juste un exemple simple.

** OK, voici ma note RE: ne se souciant pas avec l'attribut AcceptVerbs:
Dans votre scénario, vous pouvez aussi simplement choisir de faire la méthode de votre formulaire GET au lieu de POST. Étant donné que vous êtes déjà en train de «prendre des mesures» et de modifier l'état du lien pratique sur lequel vos utilisateurs cliquent, je ne verrais aucune différence. Je ne fais que mentionner cela pour être complet même si j'opterais personnellement pour ma recommandation précédente.

Bonne chance!

+0

merci .. cela semble être la bonne façon .. et je suis heureux je n'étais pas loin d'ici :) –

+0

c'est une bonne approche, si vos contrôleurs sont légers, mais si votre contrôleur grossit alors il peut devenir un cauchemar , personnellement, je n'ai jamais utilisé ce type de tous les contrôleurs puissants, ça sent le risque. – JOBG

0

je dois dire qu'il est rare de trouver quelqu'un si préoccupé par l'utilisation du verbe HTTP approprié. Je ne crois pas que l'intention originale de la spécification HTTP était de confiner toutes les soumissions d'édition de données au POST et tous les extractions à GET. Je pense que ce que tu fais va bien.

+0

merci .. il semble que j'étais vraiment préoccupé où je n'avais pas besoin. J'apprécie votre temps! –

1

Je modifier des données dans une méthode GET ... et c'est un grand NON NON

Je ne dirais pas qu'il est toujours un grand non non. HTTP dit que la méthode GET "DEVRAIT" être "sûre", c'est-à-dire qu'elle NE DEVRAIT avoir aucun effet autre que la récupération d'information. Dans ce cas, je pense qu'il est raisonnable d'étendre la définition de «sûr» pour signifier qu'il n'a pas d'effets secondaires nocifs, et en effet le seul effet secondaire possible de votre lien de vérification peut être souhaitable.

L'autre propriété que la méthode GET est censée avoir est l'idempotence: si l'utilisateur clique plusieurs fois sur le lien de vérification, c'est la même chose que si elle l'avait cliqué une seule fois. J'espère que vous avez cette propriété, car un lien de vérification est généré avec un code à usage unique.

+0

yeap .. c'est un code à usage unique .. donc je vais bien. Merci! –

-1

Si vous êtes inquiet à ce sujet alors quel est le problème avec cela?

 [AcceptVerbs(HttpVerbs.Get)] 
    public ActionResult Verify() 
    { 
     return View("Verify"); 
    } 

    [AcceptVerbs(HttpVerbs.Post)] 
    public ActionResult Verify(Guid? id) 
    { 
     if (ValidId(id)) 
     { 
      return RedirectToAction("Index", "Dashboard"); 
     } 

     return View("Verify"); 
    } 
Questions connexes