Эта статья основана на нашем опыте на Luogu.org, когда мы пытаемся использовать Nuxt.js в качестве нашего нового внешнего интерфейса. Я больше не работаю на Luogu.org, но считаю, что этот опыт по-прежнему полезен для многих разработчиков, которым сложно подключиться к существующей конечной точке API.

Ситуация

У нас есть существующий бэкэнд API (ранее он также обслуживал веб-интерфейс, как и «классический» веб-сайт), который использует механизм clientId для хранения сеансов учетной записи. Когда кто-то посещает конечную точку API, мы генерируем для него clientId и сохраняем его в файлах cookie для дальнейших посещений. Нам нужно будет реализовать функции входа и выхода на Nuxt.js.

Существующие решения

Мы знаем, что Nuxt.js имеет существующую демонстрацию того, как реализовать аутентификацию с помощью Express и express-session. Это не наш выбор, потому что:

  • нам нужно использовать Nuxt.js программно, что потеряло некоторую простоту при разработке;
  • нам нужно будет написать много кода как на стороне сервера, так и на стороне клиента;
  • может быть сложно согласовать с существующей конечной точкой API;
  • в основном он не дает пользователям, не вошедшим в систему, clientId.

@edyybordi написал похожий пост на Medium. Его решение довольно близко к моему, но он не показал полного решения.

Спасибо тем, кто сделал существующие решения. Они вдохновили меня на развертывание этого решения и этой статьи.

Архитектурный дизайн

Мы собираемся создать наш новый интерфейс отдельно как новый проект Nuxt.js, который мы называем интерфейсом. Пользователи будут напрямую использовать наше веб-приложение, и мы обеспечиваем рендеринг на стороне сервера для всех пользователей, независимо от того, вошел он в систему или нет.

Теперь, когда мы проксируем запросы пользователей с помощью Nuxt.js, нам нужно будет передавать файлы cookie конечному пользователю и обратно в конечную точку API, когда мы делаем запросы на рендеринге на стороне сервера.

Ведение сеансов

Во-первых, нам нужно иметь возможность генерировать clientIds при первом входе пользователей. В нашем случае конечная точка API предоставила нам API для простого получения clientId. На стороне Nuxt.js, если пользователь попадает на сервер без cookie clientId, мы отправляем запрос в API, чтобы получить clientId, и отправляем его реальной стороне клиента. Кроме того, поскольку первая страница пользователя отображается на сервере, нам нужно будет установить правильный clientId для сервера Nuxt.js, чтобы отправлять правильные запросы.

Только один момент: у нас нет хранилища файлов cookie на стороне сервера, но мы всегда можем имитировать файлы cookie, просто установив заголовок cookie для каждого отправляемого запроса.

Мы реализовали это с помощью Nuxt.js nuxtServerInit в store/index.js:

Хорошо, теперь у нас есть правильные clientId, хранящиеся в хранилище данных Vuex. У нас есть доступ к нему на стороне клиента. Теперь перейдем к стороне клиента. Нам нужно запустить нашу библиотеку запросов с правильным clientId, прежде чем мы будем отправлять какие-либо запросы. Не забывайте, что если мы получим новый clientId со стороны нашего сервера Nuxt.js, нам также нужно будет сохранить его в файлах cookie. Все это делается путем помещения нашего кода в beforeMount макета:

Отлично, теперь у нас есть сеансовая система в нашем веб-приложении Nuxt.js. Далее мы поговорим о входе / выходе.

Вход / выход

Помните, мы определили _currentUser и SET_USER? Давай воспользуемся этим. Поскольку наша clientId не изменится в сеансе (независимо от того, вошли вы в систему или нет), для входа мы просто нажимаем на конечную точку входа в систему API, получаем некоторую базовую информацию о текущем пользователе и сохраняем ее в _currentUser для дальнейшего использования. Сервер API сохранит текущий логин пользователя в записи этого конкретного clientId, когда мы достигнем конечной точки. Выход - аналогичная обратная операция.

Безусловно, вы можете обойтись без хранилища данных Vuex и без запроса, когда это необходимо. Мы делаем это просто для простоты, поскольку некоторые базовые данные текущего пользователя довольно часто используются на всем сайте.

Выход из системы - это в основном то же самое (наоборот). Просто нажмите конечную точку выхода и SET_USER на null.

Расширение

В нашем случае он называется clientId, но во многих других случаях это идентификатор сеанса. По сути, это одно и то же.

В большинстве случаев ваша конечная точка API не поддерживает сеанс с клиентом, который не вошел в систему. Чтобы соответствовать этой ситуации, вам нужно будет изменить некоторый код. Вам не нужно запрашивать clientId, если clientId в файлах cookie не обнаружено, и вам просто не нужно настраивать библиотеку запросов для ее одновременного использования. Разумеется, вам нужно будет уничтожить свой идентификатор сеанса после выхода из системы.

Спасибо, что прочитали всю статью. Особая благодарность Luogu.org, они позволили мне написать и опубликовать эту статью на основе кода, который я написал на Luogu.org.