Vous ne devez pas avoir à interroger la base de données directement pour l'ApplicationUser en cours.
Cela introduit une nouvelle dépendance d'avoir un contexte supplémentaire pour les démarreurs, mais à l'avenir, les tables de base de données utilisateur changent (3 fois au cours des 2 dernières années) mais l'API est cohérente. Par exemple, la users
table est désormais appelée AspNetUsers
dans Identity Framework et les noms de plusieurs champs de clé primaire ne cessent de changer, de sorte que le code dans plusieurs réponses ne fonctionnera plus tel quel .
Un autre problème est que l'accès OWIN sous-jacent à la base de données utilisera un contexte distinct, de sorte que les modifications d'un accès SQL séparé peuvent produire des résultats invalides (par exemple, ne pas voir les modifications apportées à la base de données). Encore une fois, la solution est de travailler avec l'API fournie et de ne pas essayer de la contourner .
La façon correcte d'accéder à l'objet utilisateur actuel dans l'identité ASP.Net (à cette date) est:
var user = UserManager.FindById(User.Identity.GetUserId());
ou, si vous avez une action asynchrone, quelque chose comme:
var user = await UserManager.FindByIdAsync(User.Identity.GetUserId());
FindById
nécessite que vous disposiez de l' instruction using suivante pour que les UserManager
méthodes non asynchrones soient disponibles (ce sont des méthodes d'extension pour UserManager, donc si vous ne les incluez pas, vous ne verrez que FindByIdAsync
):
using Microsoft.AspNet.Identity;
Si vous n'êtes pas du tout dans un contrôleur (par exemple, vous utilisez l'injection IOC), l'ID utilisateur est récupéré en entier à partir de:
System.Web.HttpContext.Current.User.Identity.GetUserId();
Si vous n'êtes pas dans le contrôleur de compte standard, vous devrez ajouter les éléments suivants (à titre d'exemple) à votre contrôleur:
1. Ajoutez ces deux propriétés:
/// <summary>
/// Application DB context
/// </summary>
protected ApplicationDbContext ApplicationDbContext { get; set; }
/// <summary>
/// User manager - attached to application DB context
/// </summary>
protected UserManager<ApplicationUser> UserManager { get; set; }
2. Ajoutez ceci dans le constructeur du contrôleur:
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(this.ApplicationDbContext));
Mise à jour mars 2015
Remarque: La mise à jour la plus récente du framework Identity modifie l'une des classes sous-jacentes utilisées pour l'authentification. Vous pouvez maintenant y accéder à partir du contexte Owin du contenu HttpContent actuel.
ApplicationUser user = System.Web.HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>().FindById(System.Web.HttpContext.Current.User.Identity.GetUserId());
Addenda:
Lorsque vous utilisez EF et Identity Framework avec Azure, sur une connexion à une base de données distante (par exemple, un test d'hôte local vers une base de données Azure), vous pouvez frapper au hasard la redoutable «erreur: 19 - La connexion physique n'est pas utilisable». Comme la cause est enfouie dans Identity Framework, où vous ne pouvez pas ajouter de nouvelles tentatives (ou ce qui semble être manquant .Include(x->someTable)
), vous devez implémenter une personnalisation SqlAzureExecutionStrategy
dans votre projet.