Как сделать авторизацию у SSR приложения?

Question

[goju]

Как имплементировать авторизацию у SSR приложения? Интересует в приложениях типо Nuxt или next (желательно первое).

1. Как сделать все самому, т.е. на своем хостинге? Какой порядок аутентификации нужен, какие пакеты использовать, есть ли какие-то стартер киты, лучшие практики?

2. Какие сторонние сервисы есть, кроме Auth0?

3. Какие особенности такой авторизации в целом (тонкости настройки и тд)?

Желателен такой алгоритм: ввод имейла - верификация по линку - конец авторизации, пароль. Также пойдут Google/Facebook.

Answer 1

[Тимофей]

1. Для начала по SSR не нужно заморачиваться - пускай рендеринг всегда исходит из того, что пользователь не авторизован. Всё остальное можно подгрузить на клиенте при необходимости.

Какой порядок аутентификации нужен

- довольно странный вопрос, так как это решать вам в зависимости от того, какие условия задачи :) Предполагая, что вам нужно узнать, какие есть варианты, могу сказать, что в общем их 2 - стандартная для сайтов история с куками и сессиями или получение токена и дальнейшая авторизация по нему, то есть стандартная история для всяких REST API.
2. Если имеется в виду stateless авторизация на клиенте через OAuth, то есть замечательная библиотека для этого. Если не хочется тянуть такую большую зависимость, то можно и самому реализовать - там всё довольно просто. Могу подсказать конкретнее, если интересно. На бэкенде можно взять готовое решение, коих куча для любого языка/фреймворка/CMS.
3. Тонкостей особо нет. Получил токен или куку сессии и всё. Дальше уже всё зависит от того, что конкретно нужно реализовать.

Всё, что касается процесса подтверждения email относится к бэкенду, так что тут всё стандартно, и SSR ничего не меняет. Опять же, есть куча готовых решений для любой платформы. OAuth можно тоже полностью отдать бэкенду, но тут нужно понимать, что тогда не получится этот бэкенд использовать для stateless API.

Comments

[Никита Котенко]

1. Как быть в вашем случае с перегрузкой (CTRL+R) страницы личного кабинета, если всегда отдавать рендеринг как неавторизованный?

[Тимофей]

Никита Котенко, просто фетчите данные юзера после загрузки страницы только на клиенте, с сервера можно (например) отдавать прелоадер какой-то

[Никита Котенко]

Тимофей, а где описать логику доступа к приватной странице? Где редирект описать в случае отсутствия токена/сессии/куки

[Никита Котенко]

Аа, можно потом на клиенте редирект сделать? Мне кажется это как-то не по вебовски) видел примеры с ssr где приватные страницы рендерятся на сервере

[Тимофей]

Никита Котенко, а почему нельзя редиректить на клиенте, что в этом плохого?)
Ну и на самом деле редиректить вообще, возможно, не надо. Можно просто сделать страницу с вложенным роутером, на которой показывается форма для входа, если нет юзера. Если юзер есть - просто выводить router-view, который покажет вложенные страницы.

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

[Никита Котенко]

изначально я пробовал ваш вариант на firebase (static CDN + Firestore) без ssr, но толи у них БД такая медленная, толи я делал что-то не то, хотя по их документации делал. В общем, пока клиент отправит запросы на сервер, пока получит текущего юзера, проходит секунды полторы-две. В это время пользователь видит "войти" и всё остальное меню для разлогиненого пользователя. Меня это не устроило.

Далее попробовал SSR. На приватной странице поставил проверку на авторизированного пользователя, и в случае его отсутствия редирект на логин. Естественно при перезагрузки приватной страницы всегда идёт редирект, даже если ты залогинен, т.к. пользователь не успевает инициализироваться на клиенте (1,5-2 сек.)

В итоге самым правильным способом я посчитал тот, который вы описали последним. Но он требует более глубокой подготовки) а я пока что нуб

[Тимофей]

изначально я пробовал ваш вариант на firebase

Не было у меня такого варианта, вы с кем-то меня путаете)

В это время пользователь видит "войти" и всё остальное меню для разлогиненого пользователя.

Так отдавайте прелоадер, в чём проблема-то, очевидное же решение)
У меня, например, очень просто сделано - во vuex store лежит поле user и action fetchUser, который вызывается в mounted корневого компонента (то есть только на клиенте). Поле user может иметь одно из 3-х вариантов значений: null (при инициализации стора), false или объект юзера. fetchUser устанавливает либо false (если нет токена, токен протух, юзер удалён - короче, все случаи, когда юзер не залогинен), либо объект юзера (соответственно, если юзер залогинен). Дальше очень просто:

<div v-if="user === null">Обожди, думаю я...</div>
<div v-else-if="user === false">Сюда можно только авторизованным пользователям</div>
<div v-else>Привет, {{ user.name }}!</div>

На приватной странице поставил проверку на авторизированного пользователя, и в случае его отсутствия редирект на логин. Естественно при перезагрузки приватной страницы всегда идёт редирект, даже если ты залогинен, т.к. пользователь не успевает инициализироваться на клиенте (1,5-2 сек.)

Ну, во-первых, нахер вообще юзера куда-то отправлять на другу страницу? Ему же можно прямо на той же странице показать форму, не надо редиректить никуда. Как это сделать - в моём предыдущем комменте написано. Ну и даже если вдруг ну никак без редиректа не обойтись - пожалуйста вам вариант с fetchUser:

{
    mounted() {
        fetchUser().then(user => {
            if (user === false) this.$router.replace('/login');
        });
    }
}

В итоге самым правильным способом я посчитал тот, который вы описали последним

Ну и очень зря, потом сами же с ним намучаетесь.