Nie trzeba wykonywać zapytań bezpośrednio do bazy danych dla bieżącego ApplicationUser.
Wprowadza to nową zależność od posiadania dodatkowego kontekstu na początek, ale w przyszłości tabele bazy danych użytkowników zmieniają się (3 razy w ciągu ostatnich 2 lat), ale interfejs API jest spójny. Na przykład users
tabela jest teraz nazywana AspNetUsers
w systemie tożsamości, a nazwy kilku pól kluczy podstawowych ciągle się zmieniają, więc kod w kilku odpowiedziach nie będzie już działał w niezmienionej postaci .
Innym problemem jest to, że podstawowy dostęp OWIN do bazy danych będzie korzystał z osobnego kontekstu, więc zmiany z oddzielnego dostępu SQL mogą dawać nieprawidłowe wyniki (np. Nie widzieć zmian wprowadzonych w bazie danych). Ponownie rozwiązaniem jest praca z dostarczonym interfejsem API, a nie próba obejścia go.
Prawidłowy sposób dostępu do bieżącego obiektu użytkownika w tożsamości ASP.Net (na ten dzień) to:
var user = UserManager.FindById(User.Identity.GetUserId());
lub, jeśli masz akcję asynchroniczną, coś takiego:
var user = await UserManager.FindByIdAsync(User.Identity.GetUserId());
FindById
wymaga posiadania następującej instrukcji using, aby UserManager
dostępne były metody niesynchroniczne (są to metody rozszerzenia dla UserManager, więc jeśli go nie uwzględnisz, zobaczysz tylko FindByIdAsync
):
using Microsoft.AspNet.Identity;
Jeśli w ogóle nie jesteś w kontrolerze (np. Używasz iniekcji IOC), identyfikator użytkownika jest pobierany w całości z:
System.Web.HttpContext.Current.User.Identity.GetUserId();
Jeśli nie jesteś w standardowym kontrolerze konta, musisz dodać (na przykład) następujące elementy do kontrolera:
1. Dodaj te dwie właściwości:
/// <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. Dodaj to do konstruktora kontrolera:
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(this.ApplicationDbContext));
Aktualizacja marca 2015 r
Uwaga: Najnowsza aktualizacja struktury tożsamości zmienia jedną z podstawowych klas używanych do uwierzytelniania. Możesz teraz uzyskać do niego dostęp z kontekstu Owin bieżącego HttpContent.
ApplicationUser user = System.Web.HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>().FindById(System.Web.HttpContext.Current.User.Identity.GetUserId());
Uzupełnienie:
Korzystając z EF i platformy tożsamości z platformą Azure, przez zdalne połączenie z bazą danych (np. Testowanie hosta lokalnego z bazą danych Azure), możesz losowo trafić na przerażający „błąd: 19 - Połączenie fizyczne nie jest użyteczne”. Ponieważ przyczyna jest ukryta w programie Identity Framework, w którym nie można dodawać ponownych prób (lub czegoś, co wydaje się brakować .Include(x->someTable)
), należy zaimplementować niestandardowy SqlAzureExecutionStrategy
projekt.