Czy powinienem używać wbudowanego dostawcy członkostwa dla aplikacji ASP.NET MVC?

Question

Do tej pory używałem niestandardowego dostawcy członkostwa do uwierzytelniania we wszystkich moich aplikacjach internetowych. Zaraz zacznę rozwijać moją pierwszą stronę za pomocą MVC. Zastanawiam się, czy powinienem użyć wbudowanego dostawcy członkostwa dostarczanego z ASP .NET MVC, czy też powinienem stworzyć swój własny. Moja strona musi zintegrować się z openidem, Facebookiem, Google itp. W celu uwierzytelnienia i openauth w celu uzyskania dostępu do interfejsu API. Zastanawiam się, jak łatwo byłoby użyć wbudowanego do moich potrzeb.

Answer 1

Osobiście Nienawidzę pomocą ASP.NET Membership provider, które są dostępne w ramach podstawowej ... gdy utrzymuje się z serwerem bazy danych SQL. Wszystkie tabele i widoki są takim przesadą dla pojedynczej witryny. Dla firmy hostingowej? .. może ... ale dla wszystkich witryn korporacyjnych, które zrobiłem .. to był taki żenujący przeskok i kłopot. Jeśli chodzi o rzeczywisty interfejs dostawcy, itp. ... jest bardzo dobry .. ale nadal bardzo hardcore, itp. Przesadą dla prostych-średnich stron, IMO.

Osobiście użyłbym prostego niestandardowego kodu do obsługi utrzymywania członkostwa w większości podstawowych witryn.

Następnie przechodzi do drugiego pytania: OpenId. Użyj Andrew Arnotta w wersji DotNetOpenAuth .NET framework -> to zaśmiecający kopnięcie poważnego tyłka (tm). Używanie tego jest niezależne od JAK zapisujesz dane członkowskie użytkownika do repozytorium. To znaczy. jeśli posuwasz się naprzód i korzystasz z dostawcy Sql Server + ASP.NET Membership, nadal możesz (i powinieneś) używać DotNetOpenAuth. Jeśli masz prosty, niestandardowy sposób zapisywania danych użytkownika w bazie danych (co robię), nadal możesz korzystać z DotNetOpenAuth - te dwie są niezależne od siebie.

Tak więc, IMO, nie używaj zbyt skomplikowanych elementów programu ASP.NET Membership + Sql Server, ale prostą tabelę lub dwie, aby zapisać własne dane użytkownika. Następnie MUSISZ użyć DotNetOpenAuth do wszelkich rzeczy OpenId (StackOverflow używa DotNetOpenAuth do obsługi swoich loginów OpenId).

Powodzenia :)

(jestem pewien, że moi opnions od dostawcy ASP.NET Membership + SQL Server, aby utrzymywać te informacje spowodują kilka osób do frajerem-wściekłości, tutaj).

Answer 2

Jeśli musisz zapytać, nie powinieneś pisać własnego operatora. Wykonanie zabezpieczenia jest bardzo trudne: naprawdę trudne. Błędne wykonanie jest niezwykle łatwe.

Dobra wiadomość jest taka, że ​​to, czego się chce, jest niezwykle powszechne i istnieją sprawdzone, gotowe do użycia narzędzia, które już to robią. Przykładem jest Janrain. Są też inne. Użyj istniejącego, sprawdzonego narzędzia, gdy tylko jest to możliwe.

Answer 3

Oto opcja, z której korzystam z powodzeniem.

Zasadniczo masz jednego użytkownika, który może być uwierzytelniony na wiele sposobów.

Korzystanie z wbudowanego dostawcy, który można oczywiście wyłączyć w dowolnym momencie, nie wyklucza uwierzytelniania tego użytkownika na wiele sposobów.

Gdy użytkownik dokonuje uwierzytelnienia za pomocą OpenID, Facebook itp., Dopasuj to logowanie do tabeli, która jest zgodna z określoną metodą logowania i tożsamością z tożsamością Forms, i po prostu ustaw użytkownika jako zalogowany z jego kanoniczną nazwą użytkownika.

Jeśli nowy użytkownik uwierzytelni się w Twojej witrynie i nie ma konta, po prostu automatycznie utwórz konto u dostawcy. Ustaw hasło dla losowych śmieci, ponieważ nigdy ich nie użyją. Pozwól im nadal kojarzyć z nią wiele typów logowania.

Jeśli użytkownik chce mieć również bezpośrednie logowanie, użyj standardowych mechanizmów resetowania haseł dostawcy członkostwa i podaj je.

Krótka historia: teraz używaj wbudowanego mechanizmu. Nie powstrzymuje cię to od robienia tego, co chcesz.

Answer 4

Zobacz, co się dzieje z NerdDinner. Niedawno (6 miesięcy temu) zostały zintegrowane z OpenID, a Google, Yahoo jako dostawcy oferowani. Wciąż zezwalają na wszystkie swoje "natywne" loginy. Oto przykład witryny umożliwiającej uwierzytelnianie użytkownika na różne sposoby.

Jeśli możesz odzwierciedlić niektóre z ich funkcjonalności, możesz przetasować na Facebooku, OpenAuth itp. Dużą korzyścią jest to, że jest już zaimplementowana w ASP.NET MVC, i po prostu musisz pożyczyć niektóre z tego wdrożenia.

Answer 5

Niedawno wprowadzony SimpleMembershipProvider rozwiązuje wiele problemów ze starszym członkostwem asp.net. Mianowicie łatwość użycia i kontrola nad schematem stołu użytkownika. To powinien być punkt wyjścia dla każdej nowej aplikacji (stan na 11/2012).

Zobacz poniższy link dla primera na SimpleMembershipProvider wraz z przyzwoitą historią na członkinie asp.net.

http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx