Si encuentras alguna incompatibilidad en tu código o trabajo, recuerda probar siempre en un entorno de testing antes aplicar el código al trabajo final.
Solución:
No debería necesitar consultar la base de datos directamente para el ApplicationUser actual.
Eso introduce una nueva dependencia de tener un contexto adicional para empezar, pero en el futuro las tablas de la base de datos del usuario cambian (3 veces en los últimos 2 años) pero la API es consistente. por ejemplo el users
la mesa ahora se llama AspNetUsers
en Identity Framework, y los nombres de varios principales key los campos siguieron cambiando, por lo que el código en varias respuestas ya no funcionará como es.
Otro problema es que el acceso OWIN subyacente a la base de datos usará un contexto separado, por lo que los cambios del acceso SQL separado pueden producir resultados no válidos (por ejemplo, no ver los cambios realizados en la base de datos). Nuevamente la solución es trabajar con la API suministrada y no intentar solución alterna eso.
La forma correcta de acceder al objeto de usuario actual en la identidad de ASP.Net (en esta fecha) es:
var user = UserManager.FindById(User.Identity.GetUserId());
o, si tiene una acción asíncrona, algo como:
var user = await UserManager.FindByIdAsync(User.Identity.GetUserId());
FindById
requiere que tenga la siguiente declaración de uso para que el no asíncrono UserManager
hay métodos disponibles (son métodos de extensión para UserManager, por lo que si no incluye esto, solo verá FindByIdAsync
):
using Microsoft.AspNet.Identity;
Si no está en un controlador en absoluto (por ejemplo, está utilizando la inyección de IOC), la identificación de usuario se recupera en su totalidad desde:
System.Web.HttpContext.Current.User.Identity.GetUserId();
Si no está en el controlador de cuenta estándar, deberá agregar lo siguiente (como ejemplo) a su controlador:
1. Agregue estas dos propiedades:
///
/// Application DB context
///
protected ApplicationDbContext ApplicationDbContext get; set;
///
/// User manager - attached to application DB context
///
protected UserManager UserManager get; set;
2. Agregue esto en el constructor del controlador:
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager(new UserStore(this.ApplicationDbContext));
Actualización de marzo de 2015
Nota: La actualización más reciente del marco de identidad cambia una de las clases subyacentes utilizadas para la autenticación. Ahora puede acceder a él desde Owin Context del HttpContent actual.
ApplicationUser user = System.Web.HttpContext.Current.GetOwinContext().GetUserManager().FindById(System.Web.HttpContext.Current.User.Identity.GetUserId());
Apéndice:
Al usar EF e Identity Framework con Azure, a través de una conexión de base de datos remota (por ejemplo, prueba de host local a la base de datos de Azure), puede encontrar aleatoriamente el temido “error: 19: la conexión física no se puede usar”. Como la causa está enterrada dentro de Identity Framework, donde no puede agregar reintentos (o lo que parece ser un error faltante) .Include(x->someTable)
), necesita implementar una costumbre SqlAzureExecutionStrategy
en tu proyecto
Mi error, no debería haber usado un método dentro de una consulta LINQ.
Código correcto:
using Microsoft.AspNet.Identity;
string currentUserId = User.Identity.GetUserId();
ApplicationUser currentUser = db.Users.FirstOrDefault(x => x.Id == currentUserId);
Está en los comentarios de las respuestas, pero nadie ha publicado esto como la solución real.
Solo necesita agregar una declaración de uso en la parte superior:
using Microsoft.AspNet.Identity;
Recuerda algo, que te permitimos agregar una reseña si te ayudó.