Задать вопрос
bogdan_uman
@bogdan_uman
шлЫмазл неукЪ-поцЪ

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

Здравствуйте. А как правильно реализовывать аутентификацию на клиенте. Ну сделать форму, отправить с нее POST запрос, получить ответ, сохранить ответ в переменную. И уже в зависимости от от переменой иметь доступ к одним или другим компонентам? Или как правильно?
Спасибо?
  • Вопрос задан
  • 5338 просмотров
Подписаться 9 Простой 1 комментарий
Пригласить эксперта
Ответы на вопрос 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, потому что это общий принцип применим для всех современных фреймворков.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы