Зачем делать страницу входа в одностраничное приложение отдельной страницей?

Мне интересно, почему кажется популярным, чтобы страница входа в SPA была отдельной страницей, которая не является страницей SPA (как в случае загрузки и отправки данных через запросы ajax)?

Единственное, о чем я могу думать, это о безопасности, но я не могу думать о конкретной причине безопасности. Я имею в виду, что единственное, что приходит на ум, - это то, что если ваша страница входа в систему является частью SPA, она отправляет имя пользователя / пароль через ajax, что можно увидеть с помощью таких инструментов, как firebug или веб-инспектор, однако, даже если вы отправляете его как обычный POST-запрос, есть другие инструменты, которые могут легко захватить эти данные (например, fiddler, httpscoop и т. Д.).

Есть ли что-то, что мне не хватает?

Предположительно, это экономит загрузку множества клиентских ресурсов (таких как тяжелые фреймворки JavaScript, изображения и т. Д. ), Которые требуются только для приложения.

Существуют более сложные способы достижения аналогичной цели производительности (см. « Malte Ubl & John Hjelmstad: новый эффективный подход к загрузке JavaScript - JSConf EU 2012 »), но это довольно быстро для реализации и, вероятно, столь же эффективно, особенно если Ваше веб-приложение использует почти все ваши активы в любом случае.

Вы можете увидеть это в дикой природе на сайте, подобном бета-версии http://infogr.am :

1. http://infogr.am/login/ загружаетфайлы jquery , rafahael , custom js и 3 css.
2. http://infogr.am/beta/ (главная страница SPI для приложения) загружает 10 фреймворков JavaScript, 5 внешних CSS-файлов и около 60 изображений.

Я думаю, что есть некоторые разумные аргументы за или против, и я бы сказал, что технология также играет роль в принятии решения.

Можно утверждать, что отдельная страница входа в систему позволяет использовать «Безопасность каталога». Обычно любой пользователь может видеть «страницу» входа в систему, но только пользователи, прошедшие проверку, могут просматривать «страницы» приложения и его «каталог». Маршруты также могут быть заблокированы, где / Account / отличается от / App /, и у каждого есть свой собственный «профиль безопасности».

Кроме того, если вы используете подход SPA и смешиваете аутентификацию с опытом работы приложений, логика может оказаться запутанной. Вместо того, чтобы предполагать, что пользователь «вошел в систему, потому что он здесь», вы должны постоянно проверять его статус аутентификации и спрашивать «должен ли этот пользователь быть здесь».

Кроме того, страница входа, как правило, находится на сайте, ориентированном на потребителя. Вы заходите на сайт www.yourapp.com, где есть информация об информации, контактах, поддержке и т. Д., А также страница входа в систему со страницы входа после аутентификацию, вы можете перенаправить на целый ряд целей ..

Причина, по которой я держу отдельную страницу входа в систему и почему у меня фактически совершенно другое приложение для моего сайта, ориентированного на потребителя, заключается в том, что я могу очень мало подвергать неаутентифицированному. Случайно какой-то придурок начинает стучать по моей странице входа в систему, я не хочу, чтобы это влияло на сторону приложения ... даже если вход в систему выполняет только простой аутентификационный поиск ... это как бы помогает мне не допустить, чтобы bozo'ы влияли на мой опыт пользователей .. В худшем случае мой потребительский сайт не работает, и никто не может войти, но, по крайней мере, зарегистрированные пользователи не будут знать, и их опыт не начнет замедляться .. Я не говорю, что это пуленепробиваемый выбор .. но по крайней мере я изолировал риск для неаутентифицированной области ..

Одна из причин этого заключается в том, что вы можете использовать обычные сеансы на основе файлов cookie. Пользователь входит в систему, в ответ отправляет cookie вместе с начальной главной страницей ..., а затем все последующие вызовы ajax отправляют cookie обратно на сервер.

Я вижу несколько причин сделать это:

1. Я могу использовать обычные правила контроля доступа на основе пути в web.xml.
2. Я никогда не могу быть уверен, что правильно защитил все свое Ajax-приложение, и мне нужно делать обширные тесты, чтобы быть уверенным.
3. Я могу делегировать аутентификацию фреймворку (например, Spring Security), стороннему приложению или решению SSO (например, CAS или JOSSO).
4. Я могу разрешить браузеру кэшировать имя пользователя и (опционально) пароли для пользователя.