. Niestandardowe członkostwo VS. Niestandardowe logowanie/rejestracja: uwierzytelnianie/autoryzacja

Question

Kiedy tworzę witrynę, która wymaga rejestracji i logowania, dla czegoś szybkiego bez wielu wymagań użyję członkostwa z atrybutami [Authorize] i cokolwiek. Działa dobrze w tym, co robi. Ale teraz chcę czegoś więcej. Zasadniczo Zajmuję się tworzeniem witryny przy użyciu ASP.NET MVC EF CodeFirst i chcę utworzyć podmiot użytkownika do trwałego do DB, który posiada znacznie więcej informacji. Takie informacje wymagane podczas rejestracji miałyby dodatkowe właściwości, takie jak FirstName, LastName, Gender, Country, itp.

Próbowałem już przeczytać nad implementacją niestandardowego MembershipProvider i MembershipUser, etc ... Dotarłem do tej pory ale po prostu nie spotyka się tak, jak chcę w końcu. Teraz, gdy rozwijam witrynę w PHP lub, innym razem, w ASP.NET, po prostu utworzę swoją klasę User i podam mu wszystkie właściwości potrzebne do strony rejestracji i po prostu wepchnę ją do DB. Następnie, kiedy się zaloguję, pobieram nazwę użytkownika lub adres e-mail i hasło i po prostu tworzę zmienną sesji wskazującą, czy użytkownik jest autoryzowany, czy nie.

Czy to jest w porządku? Po prostu nie rozumiem, dlaczego to całe członkostwo jest o wiele bardziej skomplikowane, niż wydaje się być, więc wydaje mi się, że brakuje mi sensu. Ponadto zauważam w aplikacji internetowej ASP.NET MVC, że kiedy jesteś uwierzytelnionego to pisze się tej linii ....

FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false); 

Jaka jest różnica między tym a ...

Session["username"] = model.UserName 

Answer 1

Zamiast iść na ścieżkę dostawcy członkostwa (ja osobiście tego nie lubię i uważam, że jest to ciężkie dla aplikacji, z którymi pracuję) rozważałeś po prostu tworzenie niestandardowego obiektu IPrinicipal/IIdentity dla swojej aplikacji i rozszerzanie go o właściwości, które chcesz z obiektu "Użytkownik"?

Zamiast dostać się do specyfiki istnieją już jakieś wielkie zasoby tak, że na okładce tego pojęcia: ASP.NET MVC - Set custom IIdentity or IPrincipal

W odniesieniu do pytania, Session["username"] jest po prostu cookie sesji. Tracisz wszystkie zalety FormsAuthentication. Na przykład w przypadku uwierzytelniania formularzy, jeśli użytkownik zażąda strony wymagającej uwierzytelnionego dostępu, a użytkownik nie zalogował się wcześniej na stronie, użytkownik zostanie przekierowany na skonfigurowaną stronę logowania za pomocą formularza.

Z Session["username"] trzeba ręcznie przetasować każdy aspekt uwierzytelniania. Silnie zalecałbym NIE robić tego.