Токен Запомнить меня в Nodejs RESTFul API

Question

Я разрабатываю RestFul Apis для мобильного приложения (приложение для Android). Я использую двухэтапную аутентификацию с использованием OTP и запомню токен. Для токена запомнить меня я сейчас использую " Помни меня" (приветствуется любая другая похожая стратегия npm). Npm в основном устанавливает уникальный токен для куки, который приложение может использовать для проверки себя. В соответствии с документацией в вышеупомянутом NPM, рекомендуется повторно генерировать токены после каждого запроса. Однако в случае, когда мобильное приложение выполняет несколько параллельных запросов, все параллельные запросы используют один и тот же токен. Это несомненно дает ошибку аутентификации. Я думаю, это обычная ситуация. Я хотел знать, есть ли стандартный способ справиться с этим?

Текущий рабочий процесс

1. Проверка подлинности запроса мобильного приложения с заданным OTP
2. После успешной проверки приложение выдает токен, который передается обратно в cookie
3. Для вызовов к защищенным API-интерфейсам приложение вызывает API-интерфейс с файлом cookie, переданным на предыдущем шаге.
4. Сервер сбрасывает токен в куки и отправляет ответ в приложение

Проблема с рабочим процессом. Приложение успешно вошло в систему и имеет действительный файл cookie.

1. Приложение выполняет вызов защищенного API /protected_api_1
2. Сервер сбросил токен в куки для указанного выше вызова, но еще не завершил ответ
3. Приложение выполняет второй вызов /protected_api_2 со старыми файлами cookie, поскольку в приложении нет нового файла cookie. Auth не работает для (3)

Answer 1

Хорошо, проверяя ваше обновление, я думаю о 3 обходных путях для этого. Допустим, у нас есть 3 действия, (a), (b) и (c), которые требуют токен для использования API.

Магазин токенов

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

Проблема с этим решением состоит в том, что если вы выполняете (a), (b) и (c) одновременно с одним и тем же токеном, то первый, кто завершит работу, обновит хранилище, а два других завершатся неудачно. Вы бы запустили их синхронно или одновременно.

Если вы хотите сделать это таким образом, возможно, было бы лучше иметь:

1. Lock: логическая переменная, которая указывает, что токен используется и что текущий запрос должен ждать, пока токен не выполнится, и обновить токен.
2. Очередь: просто связанный список, куда вы отправляете запросы, и они используются асинхронно, когда блокировка не установлена. Вы реализуете службу в другом потоке, который обрабатывает очередь, может аналогично схеме реактора.

Группировка запросов

Предположим, что ваше приложение выполняет (a), (b) и (c) очень часто. В этом случае было бы неплохо сгруппировать их в одно действие и выполнить его на сервере всего одним обратным вызовом. Это может быть сложно в вашем случае, потому что это потребует создания новых ресурсов или подумать о моделировании проблемы.

Управление истечением токена

Я видел это в некоторых проектах. Вы устанавливаете мягкое истечение срока действия токена, скажем, 15 минут (или даже меньше). По истечении этого времени вы даете клиенту новый токен, а до этого времени сохраняете тот же самый токен. (a), (b) и (c) будут работать одновременно с одним и тем же токеном. Проблемы могут возникнуть, когда вы выполняете запросы по истечении срока их действия, в зависимости от того, сколько времени требуется для их выполнения.

Я не могу дать вам более подробную информацию о реализации, потому что я не знаю, на каком языке или в какой среде вы реализуете клиент, и я никогда не создавал Android-приложение, но я думаю, что было бы неплохо попробовать один из это идеи или их смесь. С наилучшими пожеланиями.

оригинал

Я не понимаю, что вы подразумеваете под параллелью в этом контексте.

Попробуйте создать в своем приложении ресурс Token Store, который каждый параллельный запрос потребляет и обновляет после выполнения запроса.

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