Но как быть, если злоумышленник зашел по украденному токену?
У нас пользователь разлогинется через 5 мин, но если он зайдет снова, у него создастся тогда новая запись refresh_token, а та, которую украли, так же останется рабочей и будет обновляться
От этого никто не застрахован. Для уменьшения рисков, Access Token имеет короткое время жизни.
Refresh больше, но он реже используется.
Делайте разлогин по RefId и тогда все токены станут не вылидными, что были получены до разлогирования
У вас информация прописывается в токен, вы его можете распарсить и получить нужное, в БД писать не нужно. Парсится как Access, так и Refresh. Но последний еще и шифруется
Boris007, если есть несколько устройств и выход должен быть сразу со всех, то следует вводить RefId.
Для примера сущность Refs (id, userId, validFrom, validTo). И прописывать RefId как в Access Token, так и Refresh Token.
При выходе вы для записи с RefId прописываете validTo = Now. При обновлении Access Token через Refresh сходство refresh_token проверять не нужно, а просто распарсить его и проверить RefId, если он еще активен, генерите новый Access Token.
А что значит упарвление рестораном?
К примеру:
- Найм сотрудников, приготовление блюд почти не реально автоматизировать.
- Учет / расходов и доходов - уже есть 1С тот же,
R-Keeper себя и то называет - автоматизации ресторанов.
Активация от данных оборудования, где ставиться программа.
Активатор генерит QR с сылкой с кодом сгенеренным по оборудованию.
Пользователь сканирует с экрана QR получает код и вводит.
Сейчас мобильный инет есть почти везде, где есть офисы организаций.
У нас не нужно подтверждение. Каждый сервис является "источником правды", а все остальные сервисы просто обновляют у себя частичку/копию нужной информации.
Сообщения вида "Создан пользователь ID такой-то, Name такой-то" и все сервисы кто подписан и кому нужна какая-то информация о пользователе просто обновляют свои данные.
Andrei SunnyPh, А смысл в такой избаточности?
Статус код приходит в http протоколе и вам все равно придется его обрабатывать, так как если придет ошибка сетевого уровня (для примера 503), то без этого никак.
IsSuccess - определяется из статус кода.
List ErrorMessages - ошибка всегда одна, но может содержать уточняющие данные. Лучше string "Error" и list ErrorDetails
При этом Result упакован в обьект. Это почти тоже самое, что изначально спрашивали, паковать ли в массив.
А вот из полезного в случае ошибки у вас нет "Времени запроса", Url самого запроса.
"но просто переделать методы на async Task и понаставить await-ов недостаточно же, необходимо прокинуть везде CancellationToken" - достаточно.
Как у вас в примере это самое правильное
От этого никто не застрахован. Для уменьшения рисков, Access Token имеет короткое время жизни.
Refresh больше, но он реже используется.
Делайте разлогин по RefId и тогда все токены станут не вылидными, что были получены до разлогирования