Dane użytkownika w Nancy

Question

Pukam razem aplikację demonstracyjną opartą na Nancy.Demo.Authentication.Forms.

Jestem wykonawczych Claims i UserName w moim UserIdentity:IUserIdentity klasy i, jak na demo, mam UserModel z UserName.

W klasie SecureModule widzę, że Context.CurrentUser może być użyty do sprawdzenia, kto jest zalogowany, ale jak w interfejsie, dostarcza tylko nazwę użytkownika i roszczenia. Jeśli będę potrzebował uzyskać więcej danych (np. Komunikaty dla zalogowanego użytkownika) dla modelu widoku, wszystko, co mogę zobaczyć jako filtr dla zapytania db, to nazwa użytkownika, która wydaje się dziwna. Wolę używać unikalnego identyfikatora użytkownika.

Myślę, że próbuję dotrzeć do sedna, jeśli lepiej dodać dodatkowe pola do mojej implementacji IUserIdentity lub do UserModel? I gdzie je zapełnić?

Nie jestem pewien, czy moje pytanie jest takie jasne (nie jest to jasne w mojej głowie!), Ale niektóre ogólne porady dotyczące podstawowej architektury mogą okazać się przyjemnością.

Answer 1

Przepraszamy za opóźnione odpowiedzi .. nieco nerwowe w tej chwili :)

IUserIdentity jest minimum wymagane do korzystania z interfejsu wbudowany pomocników uwierzytelniania, można zaimplementować że i dodać tyle dodatkowych informacji Nancy, jak chcesz do twojej klasy; jest podobny do standardowego .net IPrincipal. Jeśli dodasz własne informacje, będziesz oczywiście musiał rzucić na swój typ implementacji, aby uzyskać dostęp do dodatkowych pól. Moglibyśmy dodać metodę CurrentUser, aby nie musieć tego robić, ale wydaje się to trochę zbędne.

Możesz przestać czytać tutaj, jeśli chcesz, lub można przeczytać na, jeśli jesteś zainteresowany w jaki formularze auth działa ..

FormsAuth wykorzystuje implementację IUsernameMapper (co prawdopodobnie jest źle nazwany teraz) w celu przekształcenia między identyfikatorem użytkownika Guid przechowywanym w pliku cookie klienta a faktycznym użytkownikiem (IUserIdentity). Warto zauważyć, że ten identyfikator GUID musi zostać zmapowany do użytkownika/id gdzieś, ale nie ma to być klucz podstawowy bazy danych, jest jedynie warstwą pośrednią między twoim (prawdopodobnie przewidywalnym) identyfikatorem użytkownika/nazwami a "tokenem" przechowywane na kliencie. Mimo że pliki cookie są zaszyfrowane i HMACd (w zależności od konfiguracji), jeśli ktoś zdąży pęknąć i zrekonstruować plik cookie auth, będą musieli odgadnąć identyfikator GUID innej osoby, aby podszywać się pod niego, zamiast zmieniać nazwę użytkownika (na "admin" lub coś podobnego) lub id (do 1 dla pierwszego użytkownika).

Mam nadzieję, że ma sens :)