Как лучше всего хранить токен API администратора в Next.js? Почувствуйте, как хранить его на стороне клиента, поскольку cookie только http является рискованным

Я работаю над электронной коммерцией, используя next.js и sylius API, а маршруты администратора API защищены с помощью JWT. Итак, чтобы получить продукты (например), мне нужно войти в API, получить токен, а затем получить продукты с помощью токена. Наиболее распространенный метод отправки токена при каждом новом запросе к API - сохранить его в файле cookie только для HTTP.

Поскольку страницы создаются статически, я чувствую, что мне не нужно (и хочу) предоставлять клиенту токен API. Итак, мне интересно, как лучше всего хранить токен?

Вот различные варианты, которые я сейчас имею в виду:

  • сохранить токен как файл cookie только для http и использовать его на стороне сервера (с прокси-сервером, использующим следующие страницы js API), чтобы вызвать sylius API. Как я уже сказал, мне неудобно хранить токен API в клиенте, это кажется мне рискованным, так как он будет доступен всем, и с этим токеном вы можете получить доступ к административному API.

  • настроить API, чтобы предотвратить истечение срока действия токена, и сохранить его в следующем js-приложении как переменную среды (.env.local), чтобы он не был доступен клиенту и мог использоваться для получения api при генерации статических страниц. Официальная тема электронной коммерции Next.Js, похоже, использует этот метод (https://github.com/vercel/commerce/blob/f770ad7a91059a2ecfbb9de1bac111dfe7016124/framework/bigcommerce/api/index.ts#L82)

  • сохранить токен где-нибудь в следующей структуре js, но не как переменную окружения (может быть, файл конфигурации?), чтобы его можно было заменить при необходимости (если срок действия токена истекает и т. д.).

  • получить токен и сохранить его в состоянии реакции, так как он будет использоваться только один раз для генерации всех статических страниц. При каждой сборке токен будет снова запрашиваться API, а затем использоваться для получения API для экспорта статических страниц с контентом. Не нужно экономить больше времени, чем на этапе строительства.

Для меня последний вариант кажется лучше, но я чувствую, что мне чего-то не хватает, я немного новичок в следующем, поэтому я не уверен, что это хорошее решение.

Спасибо :)


person David Robert    schedule 07.04.2021    source источник


Ответы (1)


Я получил отличный ответ от пользователя Reddit (supermaguireray), поэтому я публикую его как ответ здесь:

Прежде всего, в любом механизме управления сеансом правильная информация должна находиться в правильных доменах, я имею в виду, что ваш клиент может иметь доступ только к идентификационной информации, но никогда к данным, используемым на сервере, они могут быть применены к сеанс на стороне сервера, когда идентификатор для пользовательских данных, хранящихся на сервере, отправляется клиенту (предпочтительно в зашифрованном виде), или в JWT, где зашифрованная строка отправляется клиенту (идентификация) и расшифровывается на сервере ( Данные).

С учетом сказанного, единственная причина, по которой вы должны отправить токен API клиенту, - это если вам нужно получить данные непосредственно из браузера. Хранение в виде файла cookie httpOnly - наиболее безопасный способ.

В случае, если вам нужны только данные для извлечения файлов cookie на следующий сервер, чтобы отобразить ваши страницы SSG или ISR, нет необходимости отправлять файл cookie клиенту. Просто сохраните токен на своем сервере. Я бы сохранил это как переменную env. Используйте next.config.js- ›runtime-configuration.

Или вы можете сохранить дату истечения срока действия токена и сохранить учетные данные, возможно, даже в приложении DynamoDB или FaunaDB.

person David Robert    schedule 07.04.2021