Pytanie Zalecane uwierzytelnianie UX w AngularJS SPA z własnymi i zewnętrznymi profilami (Google, FB ...)


Zajmuję się tworzeniem Asp.net MVC + Web API + AngularJS SPA. Chciałbym mieć kilka rodzajów rejestracji / uwierzytelnienia:

  • własny dostawca profilu
  • zewnętrzni dostawcy, np. Google, FB itp.

Możliwe scenariusze

  1. Ponieważ mam SPA, najlepiej byłoby, gdybym mógł zatrzymać mojego użytkownika na mojej stronie, podczas gdy zewnętrzny (lub wewnętrzny) miałby miejsce. Wyświetliłbym warstwę modalną z załadowaną określoną zawartością (może nawet wewnątrz iframe). Czy można to zrobić? Przykłady online?

  2. Możliwość logowania / rejestracji została zaimplementowana w zwykły sposób w trybie pełnoekranowym kontrolerów / widoków pełnej strony Asp.net MVC, a następnie przekierowanie z powrotem do mojego SPA, kiedy to się powiedzie. Przekieruj także do zewnętrznego dostawcy, jeśli użytkownicy chcą uwierzytelnić / zarejestrować się przy użyciu zewnętrznego dostawcy.

  3. Każda inna możliwość?

pytania

  1. Jak zrobiłeś podobny scenariusz w swoim SPA lub jak poleciłbyś to zrobić?
  2. Czy powinienem używać określonych wzorców uwierzytelniania w związku z tym - na przykład zapewnić moje wewnętrzne uwierzytelnianie / rejestrację podobne do zewnętrznego, aby SAP zawsze zachowywał się w taki sam sposób
  3. Będę również musiał uwierzytelnić moje wywołania Web API po tym, jak użytkownik utwierdzi się w SPA. Wszelkie wskazówki na ten temat?

11
2018-01-22 15:30


pochodzenie


Robert, SimpleMembership można łatwo dostosować za pomocą MVC 5, aby zrobić to, co chcesz. - Dave Alperovich


Odpowiedzi:


Mogę tylko komentować własne doświadczenia, może to jest pomocne. Używamy tego samego stosu co ty, Asp.net MVC + Web API + AngularJS. Używamy serwera MVC do uwierzytelniania (Microsoft.AspNet.Identity), ponieważ nie udostępniamy publicznego interfejsu API na tym etapie, a jedynym użytkownikiem API będzie nasze SPA, które działa idealnie przy najmniejszym wysiłku.

Dzięki temu możemy ustawić usługę UserContext Angular na serwerze po zalogowaniu, który może być udostępniany przez całą aplikację Angular, menadżerowie Google Doubleclick Manager wykorzystują niektóre zalety tego podejścia podczas korzystania z usługi ng-conf prezentacja. Ponieważ Web Api obsługuje Asp.Net Identity, uwierzytelnianie i autoryzacja działają bezproblemowo pomiędzy MVC i Web Api.

Podsumowując główne za i przeciw:

Zalety:

  1. Bardzo łatwe i szybkie do wdrożenia.
  2. Działa w MVC i Web Api.
  3. Kod klienta nie musi być związany z kodem uwierzytelniającym.
  4. Ustaw UserContext Angular Service po stronie serwera raz podczas logowania, łatwo udostępniając w całym SPA za pomocą Angular DI. Widzieć prezentacja jak wspomniano powyżej.
  5. Integruje się z dostawcami zewnętrznymi tak łatwo, jak z każdą normalną aplikacją MVC.

Cons:

  1. Ponieważ przeglądarka nie wysyła części hash # adresu URL do serwera, adres URL przy logowaniu zawsze będzie korzeniem twojego SPA. Na przykład. przypuśćmy, że twoim korzeniem SPA jest / aplikacja, i próbujesz uzyskać dostęp do / app # / client, gdy nie jesteś uwierzytelniony, zostaniesz przekierowany do strony logowania, ale zwrotny adres URL będzie / app, a nie / app # / client as serwer nie ma możliwości poznania części hash adresu URL, ponieważ przeglądarka nigdy tego nie wysyła.
  2. Naprawdę nieobsługiwany projekt, jeśli planujesz udostępnić swój Web Api poza swoim SPA. Wyobraź sobie aplikację konsolową próbującą połączyć się z Twoim interfejsem API?

Krótko mówiąc, widok MVC, który wykorzystujemy do uruchomienia naszego SPA, jest chroniony za pomocą [Authorize] oraz naszych metod Web Api. W widoku MVC inicjujemy również usługę UserContext Angular, używając narzędzia Razor, aby wprowadzić dowolne właściwości użytkownika, które chcemy ujawnić. Po załadowaniu SPA za pomocą pojedynczego widoku Razor, wszystko inne jest obsługiwane przez Angular.


12
2018-01-29 14:55



Jak wtedy obsługiwałeś anonimowy dostęp do swojego SPA? W jaki sposób faktycznie wdrożyłeś funkcję logowania, jeśli wszystko jest częścią twojego SPA, w tym login? Obecnie wdrażam rejestrację / logowanie jako osobną stronę z całego SPA. Więc kiedy wejdzie się do SPA, zostaną przekierowani do logowania / rejestracji, a następnie z powrotem do SPA. Myślę, że tak naprawdę to, co najlepsze z obu światów. - Robert Koritnik
@RobertKoritnik Myślę, że źle zrozumiałeś, a może byłem niejasny. Nasz login / rejestracja znajduje się poza SPA, tylko standardowy kontroler / widok MVC. To właśnie miałem na myśli: "używamy MVC po stronie serwera do uwierzytelniania". To brzmi jak to samo, co robisz. I tak, zgadzam się, najlepiej z obu światów. - Beyers
Myślałem na odwrót, jak wyjaśniłeś problem w Cons # 1 ... Ok. Więc najwyraźniej robię to samo, co ty. Ale bardziej problematyczne było przekierowanie do Google / FB. Korzystasz z tego? Ponieważ to główny problem, który próbuję rozwiązać i zadać w tym pytaniu ... - Robert Koritnik
Ponieważ strony logowania / rejestracji to tylko standardowe strony MVC, powinna działać tak samo jak każda inna aplikacja MVC korzystająca z dostawców zewnętrznych. Jakie specyficzne problemy występują u tych dostawców? - Beyers
@anoop I używa widoku maszynki tylko do strony indeksu, gdzie ładowane jest SPA. Wszystkie kolejne widoki to standardowe pliki html, w których zdefiniowano moje szablony kątowe. Same pliki html nie zawierają poufnych danych, wszystkie dane są odbierane przez chronione wywołania Web Api, więc nie jestem zainteresowany autoryzowaniem widoków HTML. Nadzieja, która pomaga. - Beyers


Wykorzystaliśmy to, co opisaliśmy wcześniej w Beyers i działa ono dobrze w przypadku większości aplikacji i często go używam.

W naszym obecnym wniosku pracujemy nad założeniem, że separacja obaw powinna dotyczyć zarządzania trasami. 

Normalny cykl życia:

  1. Użytkownik odwiedza witrynę www.server.com
  2. Serwer wysyła down index.html
  3. Klient wysyła żądanie dotyczące zminimalizowanych zasobów (.js, .css., Itp.)
  4. Obciążenia kątowe - dyrektywa usuwa klasę ładowania z ciała (odsłaniając sekcję logowania)
    1. Angular LoginCtrl podejmuje próbę autologowania. (Login i Autologin w usłudze Angular).
    2. Serwer zwraca HTTP 401
  5. Ekran logowania pozostaje widoczny.
  6. Użytkownik loguje się (serwer podaje przeglądarce plik cookie authToken, kątowy nie zna i nie obchodzi)
  7. Angular ustawia niektóre zmienne isAuthenticated w BodyCtrl i LoginCtrl
  8. Sekcja logowania otrzymuje klasę .hidden, a zawartość otrzymuje klasę .visible (wstaw animacje ng-hide / show dla zabawy)
  9. Użytkownik rozpoczyna wypełnianie formularza, ale bierze obowiązkowe, 30 minutowe połączenie telefoniczne od krewnego.
  10. Serwer wygasł swoją sesję 10 minut temu
  11. Użytkownik kończy i wysyła formularz, ale serwer zwraca nieautoryzowane (401)
  12. http-auth-interceptor przechwytuje serwer 401, buforuje wywołanie i publikuje zdarzenie "wymagane logowanie".
  13. BodyCtrl nasłuchuje i ustawia isAuthenticated = false, a następnie klasa ng i ng-show / hide działają w sekcji logowania i zawartości.
  14. Użytkownik ponownie się loguje i wydarzenie "potwierdzone przez logowanie" jest publikowane
  15. http-auth-interceptor wysyła wiadomość z pamięci podręcznej.
  16. Użytkownik jest szczęśliwy
  17. (sekcja treści może również wyświetlać pewne widoki publiczne, ponieważ nasze api api ma pewne trasy, które są upubliczniane - wyświetlanie publicznych widoków odbywa się za pomocą prostej funkcji podobnej do uwierzytelnionej)

Struktura kątowa Ctrl:

index.html

<body>
    <!-- I am a fullscreen login element, z-index=2000-->
    <div data-ng-controller="LoginCtrl" data-ng-hide="isAuthenticated()"</div>
    <div data-ng-controller="ContentCtrl">
        <!-- fullscreen class has a z-index=2001 -->
        <section data-ng-view data-ng-class="{fullscreen: isViewPublic()}"></section>
        <!-- header and nav go here -->
    </div>
</body>

Moglibyśmy uzyskać nieco więcej kreatywności w wyświetlaniu publicznych widoków / tras, ale masz pomysł. Mamy tylko kilka tras publicznych, które służą głównie do rejestracji, resetowania hasła itp.

Zrzeczenie się: Muszę jeszcze zintegrować się z usługami uwierzytelniania zewnętrznego i oauth / zewnętrznego. Mam nadzieję, że ta konfiguracja nadal będzie zawierać wodę.

Wszelkie krytyki tego procesu są mile widziane.


7
2018-01-30 19:28



+1 dla linku do auth-przechwytywacza http. Twoje podejście wygląda na przyzwoite. - Beyers
W 4.1. czy jest to Angular kontroler logowania lub kontroler logowania po stronie serwera Asp.net MVC? Czy mógłbyś również wyjaśnić automatyczne logowanie trochę więcej? - Robert Koritnik
Przepraszam za niejednoznaczność: to kontroler kątowy - Cory Silva
Nasz Autologin (usługa kątowa) po prostu trafia w punkt końcowy, a serwer określa, czy sesja jest nadal ważna, i zwraca fragment "danych aplikacji", które następnie zostaną użyte do wykonania niektórych logiki biznesowej po stronie klienta - Cory Silva


W żadnym wypadku nie jestem zaznajomiony z backendami Microsoftu, ale mimo to spróbuję ;-):

Dobre zasoby dotyczące sposobu uwierzytelniania / autoryzacji w SPA na poziomie kątowym:

  • https://github.com/fnakstad/angular-client-side-auth
    prezentacja na żywo: http://angular-client-side-auth.herokuapp.com/login

    • Tak jak prosiłeś, istnieją dwie metody uwierzytelniania:
      • własny profil
      • dostawców zewnętrznych.
        To przekierowuje do strony internetowej dostawcy: - /
    • NodeJS na zapleczu
  • Dobra rozmowa ng-conf o tym, w jaki sposób odbywa się autoryzacja Google Doubleclick Manager podanie: http://www.youtube.com/watch?v=62RvRQuMVyg&t=2m29s
    Nie jest to dokładnie to, czego potrzebujesz (uwierzytelnianie), ale rozwiązanie zaczyna się włączać w fazę uwierzytelniania. Co więcej, może się przydać później, a podejście, które prezentuję, wydaje się naprawdę dobre.
    Slajdy: https://docs.google.com/file/d/0B4F6Csor-S1cNThqekp4NUZCSmc/edit

  • Nie mniej ważny: Opanowanie tworzenia aplikacji internetowych za pomocą AngularJS.
    Genialna, kręta książka Pawła Kozłowskiego i Pete'a Bacona Darwina.
    Ma cały rozdział lub dwa poświęcone autorom. Przedstawia niektóre złożone rozwiązania, takie jak przechwycone i przechwytujące sesje przechwytujące. Ale nawet jeśli nie użyjesz bezpośrednio podejścia do książki, te rozdziały są nadal obowiązkowe, ponieważ mogą dać ci inspirację do opracowania własnych autorskich rozwiązań.

    Uwaga - http-auth-interceptor: Jak wspomniano w książce, securityInterceptor rozwiązanie zostało pierwotnie wymyślone przez Witold Szczerba. Zobacz wpis na blogu.
    http-auth-interceptor Kod, o którym wspomina @CorySilva, to w rzeczywistości przykładowy kod do pojęć wyjaśnionych w poście.

    btw: Te 2 rozdziały są świetne, ale mam nadzieję, że Wspólnota zaproponuje w przyszłości łatwiejsze rozwiązania. Za każdym razem, gdy czytam ten przechwytujący promise apina podstawie kodu dostaję silny ból głowy :)

    btw2: Jeśli ktoś nie uważa się za eksperta od Angular, cała książka jest zdecydowanie lekturą i doskonałym uzupełnieniem po lekturze przewodnik 

Co do budowania strony logowania za pomocą ASP - sugeruję użycie ASP tylko jako backendu i middleware'a i rysowanie całej aplikacji z Angular.
Możesz zacząć od swojego podejścia i przejść do czystego Angular SPA, jeśli zacznie ono wymagać coraz więcej szalonych hacków, aby technologie ładnie się ze sobą łączyły.
Ale mogę się mylić i ten konkretny przypadek nie będzie wymagał stosowania hacków.


4
2018-01-28 14:49