bogdan_uman
@bogdan_uman
шлЫмазл неукЪ-поцЪ

Аутентификация в SPA?

Здравствуйте. А как правильно реализовывать аутентификацию на клиенте. Ну сделать форму, отправить с нее POST запрос, получить ответ, сохранить ответ в переменную. И уже в зависимости от от переменой иметь доступ к одним или другим компонентам? Или как правильно?
Спасибо?
  • Вопрос задан
  • 5324 просмотра
Пригласить эксперта
Ответы на вопрос 5
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
JWT
Ответ написан
Комментировать
@Reallyrails
UI/UX Software Engineer
Использование JWT и сохранение его в storage небезопасно.
https://www.rdegges.com/2018/please-stop-using-loc...

Предпочтительнее все-таки использовать куки. В MDN подробно описано как их использовать для хранения сессий.

Со стороны Vue все достаточно просто:
1. Создаем переменную в store и храним в ней состояние наличия установленной куки.
2. Для разделения доступа к роутам используем guard, вроде этого:
const authGuard = (to, from, next) => {
  if (store.getters.isAuthenticated) {
    next();
    return;
  }
  next('/login');
}

const router = new Router({
  routes: [
    {
      path: '/',
      name: 'Home',
      component: Home,
    },
    {
      path: '/account',
      name: 'Account',
      component: Account,
      beforeEnter: authGuard,
    },
});

3. При завершении сессии удаляем куку.
Ответ написан
megafax
@megafax
web-программист
Как Вам уже ответил Сергей Горностаев используйте для этого JWT, только данные в него можете внести например такие: идентификатор сессии для пользователя либо его id (в зависимости от безопасности приложения), срок жизни, токен для продления сессии, время жизни токена продления авторизации, выданные права (аналог разрешений в OAuth)
Таким образом при каждом последующем запросе, который требует авторизации - отправляйте дополнительный заголовок Authorization: Bearer . Этот JWT можете сохранить либо в session storage либо в local storage (тоже в зависимости от назначения) и его продлять отдельным запросом при окончании его жизни но при жизни токена на продление. Либо вообще отказаться от продления и выдавать на временной основе и если закончился - то запрашивать заново авторизацию.
Проверять выданные разрешения на то или иное действие можно на 2-х уровнях: серверной (обязательно), клиентской (желательно).
Ответ написан
Комментировать
@jakekutsel
JWT.
Складывать токен в какой-нибудь storage браузера.

Чтобы разделять доступ на клиенте, в случае vuejs, можете написать пользовательскую директиву, которая будет проверять токен и рендеретить или не рендерить проверяемый компонент.
Ответ написан
@dimashin
Вам уже посоветовали JWT. Отличная вещь, можно хранить какую-то информацию в токене (только доверять ей, конечно нельзя). Я вот только куки не советую использовать, если только в этом нет особой необходимости. Дело в том, что куки браузер хранит в открытом виде в файловой системе, а локал сторедж шифрует. Ну и читать/писать в сторедж намного проще, чем в куки. Не без нюансов, но проще.
Если коротко - отсылаете данные формы на сервер и получаете токен в ответ. Кладете этот токен в сервис, который заодно его пишет в сторедж. К каждому запросу добавляете токен в хэдер. При первой загрузке приложения проверяете есть ли в сторедже токен и если есть прямо пишете его в сервис.
Осталось только решить для себя степень защиты.
В основном можно выделить 3 типа строгости
1. Токен лежит в сторедже/памяти, но Вы ему никогда не доверяете и прежде чем пустить на любой роут отсылаете его на сервер для проверки. В большинстве случаев этот подход избыточный
2. Создаете рутовый роут для авторизации и реализуете проверку токена на сервере только на уровне этого роута, все "закрытые" роуты являются дочерними этому роуту и таким образом Вы закрываете все роуты и избавляетесь от избыточных в большинстве случаев запросов. Минусы такого подхода могут проявится при "протухании" токена.
3. Вы вообще не проверяете токен на сервере. В таком случае для производительности совершенно не важно, закрываете вы только один родительский роут или все. Минусы те же что и для варианта 2, но областей для проявления больше.
То есть, если пользователь долго оставался неактивным на странице на закртом роуте и токен протух, то пользователь все еще может перейти на любой роут и проверки не будет для варианта 2. Но если пользователь страницу перезагрузит, проверка будет. В третем же случае проверка будет всегда.
На первый взляд может показаться, что 1 вариант очень даже не избыточный, но в большинстве случаев переход на каждый роут будет сопровождаться с запросом на сервер для подгрузки данных, так что де-факто авторизация все равно будет проиходить. Главное не забывать обрабатывать 401
Ну и не забудьте так же закрыть роут авторизации для уже авторизированных пользователей такой же проверкой, только наоборот )
Да, заметьте, тут нет ни слова про vue, потому что это общий принцип применим для всех современных фреймворков.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы