Dlaczego strona logowania do aplikacji na jednej stronie jest oddzielną stroną?

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?

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:

1. http://infogr.am/login/ ładuje jquery , raphael , niestandardowe pliki js i 3 pliki css.
2. http://infogr.am/beta/ (główna strona SPI aplikacji) ładuje 10 frameworków javascript, 5 zewnętrznych plików css i około 60 obrazów.

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.

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.

Widzę kilka powodów, aby to zrobić:

1. Mogę używać normalnych reguł kontroli dostępu opartych na ścieżkach w pliku web.xml.
2. Nigdy nie mogę mieć pewności, że odpowiednio zabezpieczyłem całą aplikację Ajax i muszę przeprowadzić obszerne testy, aby mieć pewność.
3. Mogę przekazać uwierzytelnianie do frameworka (takiego jak Spring Security), aplikacji innej firmy lub rozwiązania SSO (takiego jak CAS lub JOSSO).
4. Mogę pozwolić przeglądarce na buforowanie nazwy użytkownika i (opcjonalnie) haseł dla użytkownika.