Mi chiedo se ci sia un percorso più efficiente da portare qui. Utilizzo di AspNet.Identity
Desidero consentire all'utente di accedere alla stessa casella di testo utilizzando il proprio UserName
o Email
. Sono andato avanti e ho affrontato questo problema nel AccountController Login ActionResult
. Corro il controllo prima di chiamare:Permetti all'utente di accedere con Email o UserName (AspNet.Identity)
var result = await SignInManager.PasswordSignInAsync(model.UserName, model.Password, model.RememberMe, shouldLockout: true);
Il Check:
//TODO: determine if there is a more efficient way to allow user to login either with Email || UserName
if (model.UserName.Contains("@"))
{
using (var context = new ApplicationDbContext())
{
model.UserName = (context.Users.Any(p => p.Email == model.UserName)) ?
context.Users.SingleOrDefault(p => p.Email == model.UserName).UserName :
model.UserName;
}
}
Le mie preoccupazioni sono qui due volte:
- il loro è un modo pratico più efficace per farlo.
- Sto introducendo nuovi rischi per la sicurezza o rischi di prestazioni in questo modo?
sto compreso l'intero
ActionResult
sotto per riferimento.
//
// POST: /Account/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
if (!ModelState.IsValid)
{
return View(model);
}
//TODO: determine if there is a more efficient way to allow user to login either with Email || UserName
if (model.UserName.Contains("@"))
{
using (var context = new ApplicationDbContext())
{
model.UserName = (context.Users.Any(p => p.Email == model.UserName)) ?
context.Users.SingleOrDefault(p => p.Email == model.UserName).UserName :
model.UserName;
}
}
// This doesn't count login failures towards account lockout
// To enable password failures to trigger account lockout, change to shouldLockout: true
var result = await SignInManager.PasswordSignInAsync(model.UserName, model.Password, model.RememberMe, shouldLockout: true);
switch (result)
{
case SignInStatus.Success:
return RedirectToLocal(returnUrl);
case SignInStatus.LockedOut:
return View("Lockout");
case SignInStatus.RequiresVerification:
return RedirectToAction("SendCode", new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });
case SignInStatus.Failure:
default:
ModelState.AddModelError("", "Invalid login attempt.");
return View(model);
}
}
È possibile avviare da non controllare se la voce ha un '@'. –
@RedSerpent il motivo per cui sto verificando se la voce ha un '@' è perché non voglio colpire il database con una query LINQ 'context.Users.Any' se non ne ho bisogno. Colpire il database sarebbe una soluzione migliore? Che problemi hai con il controllo di '@'? – aaronmallen
Ho avuto lo stesso problema quando avvio con Identity 1.0, ho dovuto inserire i campi email e userName come stessi. – DSR