J'ai une boîte de connexion dans mon MasterPage. Chaque fois que les informations de connexion ne sont pas correctes, je valoriser Connexion est une action de l'usercontroller, de sorte que le formulaire contenant le login a As Un utilisateur peut essayer de vous connecter de n'importe quelle page, en cas de succès, je le redirige dans sa page personnelle, mais dans cas d'erreur, je veux qu'il reste sur la même page où il a essayé de se connecter. J'ai trouvé que cela fonctionne: mais il semble que je ne retourne pas une vue appropriée, les données sur ViewData sont perdues, donc je ne peux pas montrer le Message d'erreur. Toute suggestion sur la manière de résoudre ce problème et des problèmes similaires? merci visionnementdata ["loginError"] Pour afficher le message d'erreur à l'utilisateur. action = "/user/login"<.
5 Réponses :
Pourquoi ne pas gérer le login via Ajax à la place d'un message complet? Vous pouvez facilement fournir le statut, une URL de redirection et tout message d'erreur via JSON.
$(function() {
$('#loginForm input[type=submit]').click( function() {
$('#loginError').html('');
$.ajax({
url: '<%= Url.Action("Logon","Account") %>',
dataType: 'json',
type: 'post',
data: function() { return $('#loginForm').serialize(); },
success: function(data,status) {
if (data.Status) {
location.href = data.Url;
}
else {
$('#loginError').html( data.Message );
}
}
});
return false;
});
});
Bonjour, je sais que je peux gérer cela via Ajax et c'est ce que je suis sur le point de faire, mais j'aimerais savoir comment résoudre le problème comme il peut être parfois utilisé lorsque l'utilisation d'un post simple est plus appropriée, voire plus simplement requis par un client.
Vous pouvez avoir la vue qui devrait être rendue sur l'erreur définie comme un paramètre caché du formulaire soumis. Malheureusement, vous auriez probablement également besoin de sérialiser toutes les données de modèle contenues dans cette vue pour transmettre la demande de connexion car sinon il n'y a aucun moyen de la persister entre les demandes. Le faire avec Ajax va être beaucoup plus propre. Notez que le code ci-dessus redirigera vers la page de connexion (pas la vue d'origine, cependant) si JavaScript n'est pas disponible. C'est comme ça que je voudrais le gérer - déposez l'erreur dans la page de connexion et laissez l'utilisateur récidivant de là.
Normalement pour la plupart des sites Web, lorsque l'utilisateur ne manquait pas d'authentifier (en raison du mot de passe ou de), il ira à une autre page qui aident l'utilisateur avec (comme le mot de passe récupérer ou demander à l'utilisateur de vous inscrire) qui est rare à rester dans la même page. Je pense que vous pouvez re-considérer que vous avez vraiment besoin de la navigation que vous utilisez.
OK, une solution si vous voulez vraiment coller à votre modèle, c'est que vous pouvez attacher l'erreur de connexion à l'URL. Par exemple, http://www.example.com/index.aspx?login_error=1 indique que l'erreur se produit et que vous pouvez utiliser Begin_Request (ou HTTP Module) pour capturer cela et indiquer l'état du modèle à propos de l'erreur: P>
ModelState.AddModelError(...);
Bien que mon échantillon de code ne soit pas complet, je pense que la structure de celui-ci gérera le cas où JavaScript n'est pas disponible. Dans ce cas, le formulaire de connexion fera un message complet et toutes les erreurs sont redirigées vers la page de connexion comme vous le décrivez.
D'accord sur l'utilisation d'un poste de formulaire AJAX + si aucun JS, et pour mes projets, j'utiliserais aussi bien. Mais le problème de Pistacchio persiste toujours.
Je suis confus. Ne
if (!FailedLogin) {
//Go to success page
}else{
//Add error to View Data or use ModelState to add error
return View();
}
Afficher () renvoie la vue par défaut de l'action, qui peut ou non être la vue actuelle. Si vous utilisez des vues avec des modèles, il n'inclut pas non plus le modèle utilisé par la vue actuelle, ni d'autres paramètres.
Vous voulez probablement utiliser la propriété TEMPDATA , ceci sera persisté à la demande HTTP suivante.
+1 Juste ce que je pensais. Il existe également un ensemble de filtres d'action pratiques dans MVCConTrib qui copie modélisateur vers et à partir de Tempstate afin de disposer des informations de validation disponibles après la redirection. Voir l'article 13 dans cet article pour un exemple weblogs.asp.net/rashid/archive/2009/04/01/...
Rappelez-vous que Tempdata utilise si toutes les implications.
L'exemple suivant vous aiderait, espérons-le vous aider à résoudre ce problème:
private bool ValidateLogOn(string userName, string password)
{
if (String.IsNullOrEmpty(userName))
{
ModelState.AddModelError("username", "You must specify a username.");
}
if (String.IsNullOrEmpty(password))
{
ModelState.AddModelError("password", "You must specify a password.");
}
if (!MembershipService.ValidateUser(userName, password))
{
ModelState.AddModelError("_FORM", "The username or password provided is incorrect.");
}
return ModelState.IsValid;
}