UrbanRider May 26 2021 at 12:57

RESTful backend приложение. Базовый шаблон

17 min

12K

JavaScript *Programming *Node.JS *

Tutorial

Comments 9

yarkov May 26 2021 at 13:21

Всё хорошо, но я бы на TypeScript писал. Как можно начинать сейчас проект на чистом JS - я не понимаю.

Не навязываю никому, просто ИМХО.

UrbanRider May 27 2021 at 09:06

В целом соглашусь. Опять же тот, кто умеет в TypeScript скорее всего легко сможет перевести данный шаблон на ts, не так уже и сложно(настроить tsconfig, прописать типы. Ну можно переделать в ООП, написать классы и интерфейсы, для библиотек, которые используются в проекте описания типов есть почти для всех точно)

Этот гайд настроен больше на тех, кто осваивает JS, а без нормального знания JS, лезть в TS не стоит, имхо.

apapacy May 26 2021 at 22:06

Проверять на клиенте время жизни токен нерационально. Лучше икак правидл все так и делают проверять время ж зни токена на сервере и форм ртвать ответ со статусом что токен истек .

UrbanRider May 27 2021 at 08:55

На счет рациональности, готов порассуждать. Если делать на сервер, то нам придется слать больше запросов. Например: клиент запрашивает инфу и передает токен, сервер видит что токен истек и шлет ответ, что токен истек, тогда клиент шлет запрос на рефреш, получает новый токен и потом шлет изначальный запрос. Получается 3 запроса.

Если делать на клиенте, мы получаем 2 запроса, и с меньшей задержкой.

apapacy May 26 2021 at 22:12

.сохраняем токе в базе, ищемтокен в базе…
Эти действия противоречат смыслу заложенному в jwt. Товары как правило не нужно сохранять в базе. А валидация их проводится уриптографичкхеским способом а не поиском в базе.

UrbanRider May 27 2021 at 08:59

не совсем понимаю, причем тут товары. В данном случае jwt используется для идентификации пользователя и все.

Посмотрите, как работает стратегия passport-jwt. В целом да, можно избавиться от проверок базы и загнать весь объект пользователя в jwt, но тогда защита будет хуже, есть шанс на компрометацию access-token, который у клиента в локалсторадже лежит, а там будут личные данные пользователя, а в таких местах хранить данные не красиво, по отношению к пользователю. Опять же готов к обсуждению. Дайте, пожалуйста, развернутый ответ.

apapacy May 27 2021 at 21:13

По поводу развернутого ответа я практически на все вопросы ответил в своем сообщении https://habr.com/ru/post/532130/ Некоторые моменты не имеет смысл обсуждать Их скорее нужно изучить, пранализировать. У JWT есть кейсы когда его нужно прирменять. Вот например вы упомянули что токен лучше проверять по дате локально и это якобы уменьшает нагрузку на сервер. В то же время храните токен в базе что как раз увеличивает нашгрузку на сервер. Почему оба варианта не соответсвуют смыслу применения JWT. Во-первых, проверка токена на сервере происходит без оращения к тяжнлвм скриптам и базе данных. Например то можно делать на уровне ngiinx или haproxy. А поскольку процесс это хаклчается в проверке подписи (а не пробванием токена по базе) то это процесс можно горизонтально масштабировать. Что касается хранения токена в локалсторе то если данные чувстивтельны то их можно шифровать.

Товары это токены который мой телефон исправил на товары а я не заметил.

Toori May 28 2021 at 12:21

А как происходит аутентификация с разных устройств?

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

Или для таких сценариев какую-то другую схему с jwt используют?
Спасибо.

UrbanRider May 28 2021 at 12:25

В данной реализации каждая авторизация порождает новую пару jwt+refresh, соответственно если вы авторизуетесь на другом устройстве, то refresh будет для того устройства и когда ваш access-token истечет вас выкинет. Т.е. нельзя работать под одним аккаунтом на разных устройствах одновременно.

Если нужно работать одновременно с нескольких устройств, логику работы надо менять.