Zastanawiam się, dlaczego wydaje się popularne, aby strona logowania do SPA była oddzielną stroną, która nie jest stroną SPA (jak w załadowanym i wysyłającym dane przez żądania ajax)?
Jedyne, co mogę wymyślić, to bezpieczeństwo, ale nie mogę wymyślić żadnego konkretnego powodu. Mam na myśli jedyną rzeczą, która przychodzi na myśl, że jeśli twoja strona logowania w części SPA, wysyła nazwę użytkownika / hasło przez ajax, które mogą być widoczne przez takie narzędzia jak firebug lub inspektor internetowy, nawet jeśli wysyłasz to normalnie Żądanie POST, istnieją inne narzędzia, które mogą łatwo przechwycić te dane (takie jak skrzypek, httpscoop itp.).
Czy czegoś brakuje?
javascript
architecture
ryanzec
źródło
źródło
Odpowiedzi:
Przypuszczalnie ma to zaoszczędzić ładowanie wielu zasobów po stronie klienta (takich jak ciężkie frameworki JavaScript, obrazy itp. ) , Które są wymagane tylko przez aplikację.
Istnieją bardziej zaawansowane sposoby osiągnięcia podobnego celu w zakresie wydajności (patrz „ Malte Ubl i John Hjelmstad: Nowe, wydajne podejście do ładowania JavaScript - JSConf EU 2012 ”), ale jest to dość szybkie do wdrożenia i prawdopodobnie równie wydajne, szczególnie jeśli Twoja aplikacja internetowa i tak wykorzystuje prawie wszystkie zasoby.
Możesz to zobaczyć na wolności w witrynie takiej jak http://infogr.am beta:
źródło
Myślę, że istnieją uzasadnione argumenty za lub przeciw, i powiedziałbym, że technologia również odgrywa rolę w podejmowaniu decyzji.
Można argumentować, że osobna „strona” logowania umożliwia korzystanie z „Directory Security”. Zasadniczo każdy może zobaczyć „stronę” logowania, ale tylko uwierzytelnieni użytkownicy mogą przeglądać „stronę” aplikacji i jej „katalog”. Trasy można również zablokować, gdzie / Konto / jest inne niż / App / i każda ma swój własny „profil” bezpieczeństwa.
Ponadto, jeśli używasz podejścia SPA i łączysz uwierzytelnianie z doświadczeniem aplikacji, logika może się zawić. Zamiast zakładać, że użytkownik jest „zalogowany, ponieważ jest tutaj”, musisz stale sprawdzać jego status uwierzytelnienia i pytać „czy ten użytkownik powinien być tutaj”.
Ponadto strona logowania znajduje się ogólnie na stronie skierowanej do konsumenta .. idziesz do www.yourapp.com i zawiera ona informacje na temat informacji, kontaktu, wsparcia itp. Oraz stronę „logowania” ze strony logowania, po uwierzytelnianie, możesz przekierować do wielu celów.
Powodem, dla którego mam osobną stronę logowania i dlaczego mam zupełnie inną aplikację dla mojej witryny skierowanej do konsumentów, jest to, że mogę bardzo niewiele narazić na nieuwierzytelnione. Przez przypadek jakiś kretyn zaczyna walić w moją stronę logowania, nie chcę, żeby wpłynęło to na stronę aplikacji ... nawet jeśli logowanie polega tylko na prostym wyszukiwaniu uwierzytelnienia ... to trochę pomaga mi powstrzymać bozo przed wpłynięciem na mój doświadczenia użytkowników ... W najgorszym przypadku moja strona dla konsumentów nie działa i nikt nie może się zalogować, ale przynajmniej zalogowani użytkownicy nie będą wiedzieć, a ich doświadczenie nie zacznie zwalniać. Nie mówię, że to jest kuloodporny wybór ... ale przynajmniej odizolowałem ryzyko od nieuwierzytelnionego obszaru.
źródło
Jednym z powodów jest to, że możesz wtedy korzystać z normalnych sesji opartych na plikach cookie. Użytkownik loguje się, odpowiedź wysyła ciasteczko wraz z początkową stroną główną ... a następnie wszystkie kolejne wywołania ajax wysyłają ciasteczko z powrotem na serwer.
źródło
Widzę kilka powodów, aby to zrobić:
źródło