2015-04-10 8 views
7

W mojej aplikacji korzystam z tożsamości ASP.NET i mam różne typy użytkowników (nauczyciel, uczeń, ...), które mają swoje własne właściwości, dla nauczyciela mam Experience, Languages Spoken, Certifications, Awards, Affiliations, ..., a dla ucznia mam różne właściwości. W ten sposób nie mogę używać ról z powodu różnych informacji na użytkownika. Tak więc wszyscy oni są użytkownikami, co oznacza, że ​​mogą zalogować się na mojej stronie. Również mają wspólne informacje na temat rejestracji: First Name, Last Name, Email, Password Teraz, co myślisz i jaka jest najlepsza opcja do zrobienia tego? Czy powinienem utworzyć klasę dla każdego użytkownika, który dziedziczy po IdentityUser<int, CustomUserLogin, CustomUserRole, CustomUserClaim>? Każdy pomysł?Jak zdefiniować różne typy użytkowników w tożsamości ASP.NET?

PS: Znalazłem kilka rozwiązań dla robią, że na przykład here rekomendacja jest użycie roszczeń, lecz to nie jest wystarczająco jasne dla mnie, właściwie Roszczenia są trudne częścią układanki, a nie to, czego są? :), Byłoby lepiej mieć przykłady. Dzięki

+0

"W ten sposób nie mogę używać ról z powodu różnych informacji na użytkownika." Właściwości i role klasy to dwie zupełnie różne rzeczy; możesz tworzyć dowolne role odpowiadające wymaganiom bezpieczeństwa aplikacji, niezależnie od właściwości klasy. – IrishChieftain

+0

Tak, wiem. Mam na myśli, że te właściwości, których potrzebuję, należą do użytkowników, a nie ról. –

+0

może ten artykuł pomoże ci toczyć we właściwym kierunku: http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-dla-asp-net- deweloper/ – rogerdeuce

Odpowiedz

8

Apporach # 1:

Podejście Roszczenia mogą być droga. Więc wyprowadzasz z IdentityUser w zwykły sposób i dodajesz wspólne właściwości do klasy pochodnej. Następnie dla każdego typu użytkownika można dodać dodatkowe roszczenia za pomocą UserManager.AddClaimAsync.

Załóżmy na przykład, że utworzysz nową klasę użytkowników o nazwie AppUser. Możesz następnie wykonać:

AppUser teacher = new AppUser { /* fill properties here */ }; 
/* Save User */ 
await userManager.AddClaimAsync(teacher.Id, new Claim("app_usertype", "teacher")); 
await userManager.AddClaimAsync(teacher.Id, new Claim("app_grade", 4)); 
await userManager.AddClaimAsync(teacher.Id, new Claim("app_exp", 10)); 
await userManager.AddClaimAsync(teacher.Id, new Claim("app_awards", "Award1,Award2")); 
await userManager.AddClaimAsync(teacher.Id, new Claim("app_langspoken", "English,French,German")); 

AppUser student = new AppUser { /* fill properties here */ }; 
/* Save User */ 
await userManager.AddClaimAsync(student.Id, new Claim("app_usertype", "student")); 
await userManager.AddClaimAsync(student.Id, new Claim("app_grade", 2)); 

Będą one zawierać różne roszczenia dla różnych typów użytkowników. Tak więc teacher twierdzi, że ma "app_experience" z "10", "app_awards" z "Award1" i "Award2", itp. Z drugiej strony student twierdzi, że ma tylko "app_grade" z "2".

Zasadniczo pierwszy parametr identyfikuje typ roszczenia, a drugi parametr to dane, które tworzą kopię zapasową tego roszczenia. Typ może być dowolny, więc wybierz coś, co ma sens dla twojej aplikacji i może prefiksować każdą nazwę, aby odróżnić ją od innych. W przypadku, gdy właśnie dodałem "aplikację".

Następnie można użyć UserManager.GetClaimsAsync, aby wszystkie wnioski o użytkownika i wyszukiwania zwracane listy do roszczenia jesteś zainteresowany.

Podejście nr 2

Inne podejście byłoby stworzenie klasa AppUser, a następnie Teacher i Student wywodząca się od AppUser. W tych klasach dodajesz właściwości, które w przeciwnym wypadku zostałyby dodane jako roszczenia w powyższym przykładzie.

Lekkim minusem tego jest konieczność utworzenia osobnych tabel dla każdego z tych różnych użytkowników z relacjami z powrotem do tabeli użytkowników tożsamości ASP.NET.

Dodatkowo, użycie FindByUserNameAsync, FindByEmailAsync itp. Zwróci tylko jeden typ TUser, w tym przypadku AppUser. Ponadto te metody będą dotyczyć tylko jednej tabeli, AspNetUsers, więc pobranie tych informacji z odpowiedniej tabeli Teacher lub Student będzie należało wykonać.

1

Ponieważ wszyscy użytkownicy będą mieć niektóre z tych samych właściwościach byłoby sensowne, aby utworzyć klasę „User”, aby pomieścić wszystkie właściwości, które będą takie same dla nauczycieli, studentów, itp

bym następnie utwórz klasę dla każdego typu użytkownika, korzystając tylko z właściwości specyficznych dla tego typu użytkownika. W tej klasie zaliczam UserId jako jedną z właściwości, więc masz związek od głównej grupy do ich poszczególnych typów. Patrz poniżej:

Klasa użytkownika: UserId (Primary Key), Imie, Nazwisko , logowania Hasło, Itd

Wychowawca: UserId (klucz obcy), klasy nauczał Doświadczenie, Awards, Itd

Klasa Student: UserId (klucz obcy), stopnia, Wyróżnienia, Itp.

Istnieje wiele sposobów na robienie tego, co robimy, więc jest to tylko jedna sugestia. Powodzenia!

Powiązane problemy