Хорошо, что я создал свою собственную систему аутентификации, которую я собираюсь использовать в своем API.
Простое объяснение:
Вкл /signup
пользователя вводит имя пользователя, пароль и т.д. API предоставляет пользователю tokens
которые хранятся в пользовательском документе в базе данных. API также возвращается с телом ответа с новым refreshToken
и accessToken
, моя мысль вот так что приложение может легко хранить маркеры на телефоне для последующих обращений к API.
/login
- это почти то же самое, за исключением того, что вы указываете только имя пользователя и пароль.
Один из маршрутов в API - это /article
который вы можете GET
& POST
.
Теперь, если вы пытаетесь, например, GET
в /article
и ваш accessToken
будет истек API будет автоматически вызывать /token
, который требует refreshToken
в заголовке, то /token
будет предоставить вам новый accessToken
и запросить тот же маршрут, вы пытаетесь get (в этом случае /article
) с новым accessToken
в заголовке.
Вопрос: Каков наилучший способ обновить accessToken
в приложении с помощью нового accessToken
?
router
.route('/article')
.get(
AuthenticateController.authenticate,
NewsController.getAllArticles,
AuthenticateController.sendAuthorize
);
Вот как я это делаю сейчас, AuthenticateController.authenticate
аутентифицирует accessToken и проверяет, истек ли он, и все, что затем вызывает next()
.
NewsController.getAllArticles
получает все статьи, а также вызывает next()
поэтому AuthenticateController.sendAuthorize
может запускать и возвращать новый accessToken
в заголовке ответа при получении нового (я думал, что это упростит использование нового токена в приложение). Здесь возникает мой вопрос, потому что я не могу вызвать next()
на каждом маршруте, потому что на некоторых маршрутах основная функция уже возвращает ответ, а это означает, что next()
не может быть вызван, что означает, что AuthenticateController.sendAuthorize
никогда не будет запущен. Я хочу, чтобы AuthenticateController.authenticate
был единственным промежуточным программным обеспечением, необходимым для аутентификации пользователя.
Вместо того, чтобы ждать последнего маршрута для отправки нового токена, вы должны перенести промежуточное ПО sendAuthorize
выше основного ответа маршрута (или объединить его с authenticate
) и вместо этого отправить 401 Unauthorized
ответ с новым токеном. Затем обновите токен на клиенте и отправьте запрос повторно.
Похоже, глупая практика отправить действительный ответ с недопустимым accessToken
. В конце концов вы захотите сделать недействительными маркеры (т.е. при выходе из системы или изменении пароля), и вы не хотите, чтобы пользователи могли выполнять запросы без проверки подлинности.