Навіщо робити сторінку входу для однієї сторінки додатком окремою сторінкою?

28

Мене цікавить, чому, здається, популярним є те, що сторінка входу в SPA є окремою сторінкою, яка не є сторінкою SPA (як у завантажених і надсилаючих даних через ajax запити)?

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

Щось мені не вистачає?

javascript architecture

— ryanzec
джерело

2

Я не думаю, що в цій справі є чи має бути причина. Я б заперечив, чому ні?

— Стівен Еверс

1

Мій аргумент проти цього полягав би в тому, що мати сторінку входу як окрему сторінку HTML, тоді як решта програми - це архітектура SPA, здається дивним, не маючи реальної користі (хоча точка, яку зробив msanford, має заслугу).

— ryanzec

@ryanzec Дякую Я додав приклад, намагаючись проілюструвати, що реальна користь. По-перше, заощадження відстрочення завантаження активів в іншому місці є незначним, особливо у випадку невдалого входу (або призупинення рахунку тощо). По-друге, це набагато швидше впровадити, ніж більш складна асинхронна система модулів на основі залежностей, і життєвий цикл розробки є важливим фактором (див. Офісну мантру Opbeat * (містить вульгарність)).

— msanford

"навіть якщо ви надсилаєте його як звичайний POST-запит, є й інші інструменти, які можуть легко зафіксувати ці дані". Напевно ваша форма входу захищена HTTPS ?

— ajlane

@ajlane так, мій логін (і власне, вся програма) буде працювати за HTTPS

— ryanzec

18

Імовірно, це зекономити завантаження безлічі клієнтських активів (наприклад, важкі рамки JavaScript, зображення тощо ), які потрібні лише додатку.

Є більш складні засоби для досягнення подібної мети ефективності (див. " Malte Ubl & John Hjelmstad: Новий, ефективний підхід до завантаження JavaScript - JSConf EU 2012 "), але це досить швидко здійснити і, мабуть, так само ефективно, особливо якщо ваш веб-додаток так чи інакше використовує майже всі ваші активи.

Ви можете побачити це в дикій природі на такому веб-сайті, як http://infogr.am beta:

http://infogr.am/login/ завантажує jquery , raphael , користувальницькі js та 3 файли css.
http://infogr.am/beta/ (головна сторінка SPI для програми) завантажує 10 фреймворків javascript, 5 зовнішніх файлів css та близько 60 зображень.

— мсанфорд
джерело

Оновлення: У 2016 році з angular2 front-end та JBoss back-end ми все ще робимо це з тієї ж причини.

— msanford

18

Я думаю, що є певні розумні аргументи «за» або «проти», і я б сказав, що технологія також відіграє певну роль у прийнятті рішення.

Можна стверджувати, що окрема вхідна "сторінка" дозволяє використовувати "Безпека каталогів". Зазвичай кожен може бачити "сторінку" для входу, але лише користувачі, що мають автентифікацію, можуть переглядати "сторінку" програми та це "каталог". Маршрут також може бути заблокований, де / Account / відрізняється, ніж / App /, і кожен має свій "профіль" безпеки.

Крім того, якщо ви використовуєте SPA-підхід і змішуєте автентифікацію з досвідом застосування, логіка може заплутатися. Замість того, щоб припускати, що користувач "увійшов до системи, оскільки він тут", ви повинні постійно перевіряти їх статус аутентифікації та запитувати "чи повинен цей користувач перебувати тут".

Крім того, сторінка входу, як правило, знаходиться на сайті для споживачів. Ви переходите на www.yourapp.com, і на ньому є інформація про інформацію, контакт, підтримку тощо. Та "сторінку входу" на сторінку входу автентифікації, ви можете перенаправити цілу низку цілей.

Причина, за якою я зберігаю окрему сторінку входу, і чому я насправді маю зовсім інший додаток для свого сайту "для споживачів", полягає в тому, що я можу дуже мало піддавати неаутентифікацію. Випадково якийсь дебіл починає стукати на мою сторінку входу, я не хочу, щоб це впливало на додаток речей .. навіть якщо логін робить лише просту аутентифікацію пошуку. Це допомагає мені утримати вплив bozo досвід користувачів. Найгірше, що мій веб-сайт споживача не працює, і ніхто не може ввійти, але принаймні зареєстровані користувачі не знають, а їхній досвід не починає сповільнюватися. Я не кажу, що це вибір, який підтверджує куля .. але принаймні я виділив ризик для несанкціонованої області ..

— ханзоло
джерело

1

Безпека часто є великою причиною.

— JustinC

1

@JustinC: поясніть мені на окремій сторінці для входу в більш безпечний?

— ryanzec

Не обов'язково через атрибути файлової системи (але це може бути, якщо така ситуація вимагає), але контейнер / програмне забезпечення / сервлет для веб-додатків / час виконання за допомогою застосування методів вибіркового аутентифікації / авторизації, застосованих або на конкретному ресурсі, або до групи ресурсів в цілому (на практиці - каталог): для сторінки входу та окремих статичних ресурсів (зображення, таблиці стилів, сторінки помилок) часто анонімного доступу достатньо; для інших сторінок може знадобитися більш конкретна автентифікація / авторизація.

— JustinC

2

Аутентифікація поза додатком ізолює аутентифікацію від того, щоб її турбували. Фактична безпека буде залежати від впровадження та технології

— hanzolo

update 2017: IdentityServer

— hanzolo

10

Однією з причин цього є те, що потім можна використовувати звичайні сеанси на основі файлів cookie. Користувач входить у систему, відповідь надсилає файли cookie разом із початковою основною сторінкою ..., а потім усі наступні виклики ajax відсилають файл cookie назад на сервер.

— ГрандмайстерB
джерело

6

Я бачу кілька причин для цього:

Я можу використовувати звичайні правила контролю доступу на основі маршруту в web.xml.
Я ніколи не можу бути впевнений, що я захистив всю програму Ajax належним чином, і мені потрібно зробити обширні тести, щоб бути впевненим.
Я можу делегувати автентифікацію на рамку (наприклад, Spring Security), сторонній додаток або рішення SSO (наприклад, CAS або JOSSO).
Я можу дозволити браузеру кешувати ім’я користувача та (необов'язково) паролі для користувача.

— n0rm1e
джерело