ASP.NET MVC Post de @Url.action()

J'ai le contrôleur suivant généré automatiquement par asp.net

    //
    //POST: /Account/LogOff
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult LogOff()
    {
        AuthenticationManager.SignOut();
        return RedirectToAction("Index", "Home");
    }

Maintenant, j'ai un bouton de déconnexion. Actuellement, il ressemble à ceci:

   <div class="userdrop">
                <ul>
                    <li><a href="@Url.Action("Manage", "Account")">Profile</a></li>                       
                    <li><a href="@Url.Action("LogOff", "Account")">Logout</a></li>
                </ul>
            </div><!--userdrop-->

Mais il ne fonctionne pas et je devine que c'est parce qu'il est un Post de la méthode d'action.

Comment pourrais-je aller sur "déconnexion" ?

[MODIFIER]

Pourquoi est-il auto-produit comme un Http Post? Est-il plus sûr de cette façon? N'est-il pas envoyer le cookie avec elle quand il se déconnecte?

InformationsquelleAutor Zapnologica | 2014-01-28
  1. 9

    Comment pourrais-je aller sur "déconnexion" ?

    À l'aide d'un formulaire au lieu d'un point d'ancrage:

    <li>
    @using (Html.BeginForm("LogOff", "Account"))
    {
        @Html.AntiForgeryToken()
        <button type="submit">Logout</button>
    }
</li>

    On pourrait appeler le CSS des assistants de style ce bouton ressemble à une ancre si vous le souhaitez. Mais le sémantiquement correcte de l'élément dans ce cas est un formulaire html qui permet d'envoyer un POST verbe.

    • +1 pour le submit code du bouton - et comme une note ici, j'ai eu d'importants problèmes avec AntiForgeryToken sur l'équilibrage de charge les environnements d'hébergement partagés. Connaissez-vous une solution pour ce problème? C'est pourquoi j'ai arrêté y compris dans mes formes et je ne l'aime pas du tout. Il est probable que le commettant ainsi.
    • La bonne solution. De toute façon à maintenir les deux éléments de la même manière? Comme mon css affiche maintenant un bouton et pas le même point de vue que ci-dessus?
    • Je crois que j'ai répondu à ma propre question en regardant une autre de vos réponses. La clé est de mettre la machineKey dans le Web.config de sorte que c'est cohérente à travers toutes les instances de l'application. J'ai eu à faire que de résoudre un problème différent, le "rester connecté" problème. Je me demande maintenant ce que - quels sont les risques associés?
    • oui un bouton de soumission n'est pas comme un point d'ancrage. Donc, tout ce que vous avez à faire est d'utiliser le CSS pour le faire paraître comme vous le souhaitez. Je ne suis pas un CSS spécialiste, vous pourriez commencer une autre question sur ce sujet. La réponse à votre question ici, est d'utiliser un formulaire et un bouton submit qui vous permettra d'envoyer une requête POST et le antiforgery jeton.
    InformationsquelleAutor Darin Dimitrov
  2. 7

    Il n'y a aucune raison pour que ce soit un HttpPost. Je sais que c'est générée de cette façon, mais vous n'êtes pas vraiment POSTing toutes les données. Il suffit de supprimer l'attribut et il fonctionnera comme est.

    Maintenant, si vous voulez qu'il fonctionne avec le HttpPost ensuite, vous aurez besoin de mettre cela dans une Form et d'en faire une submit bouton ou submit la forme onclick.

    <li>
    @using (Html.BeginForm("LogOff", "Account",
        FormMethod.Post, new { id = "LogOffForm" }))
    {
        @Html.AntiForgeryToken()
        <a href="@Url.Action("LogOff", "Account")"
            onclick="$('#LogOffForm').submit();">Logout</a>
    }
</li>
    • + 1 pour une autre solution. Certains frameworks CSS et les templates ne seront pas comme les ajoutés à partir de là. L'action de Fermeture de session nécessite également l'anti-contrefaçon champ de formulaire "__RequestVerificationToken" par défaut. L' [ValidateAntiForgeryToken] attribut doit être supprimée. J'ai du mal avec les ramifications de cette abit....mais après tout, elle est limitée à DE-Auth
    • est-il un problèmes de sécurité avec la suppression de l'anti-faux jeton et de décisions plutôt que d'un poste?
    • POST doit être utilisé de sorte qu'il force le navigateur à frapper le serveur. À l'aide de GET, le navigateur pourrait utiliser une copie mise en cache et n'est pas correctement déconnecter du serveur.
    InformationsquelleAutor Mike Perrenoud
  3. 3

    Vous êtes en droit qu'il a à faire avec [HttpPost] attribut, qui ne permettent que de HTTP POST de demandes. Régulier des ancres HTML déclencher des requêtes HTTP GET, à cet effet, votre exemple ne fonctionne pas.

    Une solution pourrait être quelque chose comme ceci:

    @using (Html.BeginForm("LogOff", "Account", FormMethod.Post, 
          new { id = "logoutForm" })) {
    @Html.AntiForgeryToken()
    <button type="submit">Log off</button>
}

    Je crois que c'est proche de ce que le modèle par défaut dans MVC4.

    Remarquez comment nous avons également passer le long de l'anti faux jeton, requis par le [ValidateAntiForgeryToken] attribut.

    • +1 pour une solution qui ne nécessite pas de jQuery 😀
    • LOL, j'ai supprimé le besoin de JS au total aujourd'hui.
    InformationsquelleAutor Christofer Eliasson