SG
В .env добавил APP_PORT=8082 и всё
Size: a a a
2021 June 16
V
а что у тебя это?
SG
SG
Просто по доке через https://laravel.build/app?with=pgsql
V
хз поставь владельца юзера sail
АП
Здравствуйте, подскажите по логике авторизации по access\refresh токенам для нескольких устройств одного пользователя? не могу понять как инвалидировать украденные токены и не навредить реальному клиенту?
у меня есть ход мылсей и он такой
- access_token (user_id + fingerptint) - в базе его не храним, в нагрузке идентификатор клиента и его устрйокста
- refresh_token - храним вместе с user_id, fingerprint, exp_at
1) В базе у нас есть таблица
user_id, fingerprint, refresh_token, exp_at
те строка соответствия id юзера, какого-то ключа устройства (фингерпринт) и сам рефреш-токен с датой валидности
2) злоумышленник украл наши токеныи шлет запрос на обновление токена (шлет ведь сразу оба токена?)
из access_token мы получаем (user_id + fingerprint), хоть он и просрочен
смотрим рефреш токен в базе
те ищем строку user_id + fingerprint + refresh_token
есть такая строка (логин нашего настоящего клиента ее туда поместил)
3) для злоумышленника генерируем новый аксес-токен и новый рефреш-токен обновляем в бд запись
user_id + fingerprint + refresh_token
злоумышленник всем этим прекрасно пользуется неограниченное время
4) наш пользователь аналогично пользуется своим аксес-токен, но он у него заканчивается и он шлет запрос обновления
5) мы в базе ищем его рефреш токен
user_id + fingerprint + refresh_token
и не находим, так как его обновил наш злоумышленник со соим фингерпринт, используя ранее украденные токены
6) соответсвенно клиента кидаем на авторизацию, он логинится и получает свои 2 токена, а злоумышленник продолжает пользоваться токенами. Приложение думает что просто клиент наш авторизован с 2ух устройств сразу и все в норме
Что-то я н понимаю, подскажите пожалуйста где ошибка?
у меня есть ход мылсей и он такой
- access_token (user_id + fingerptint) - в базе его не храним, в нагрузке идентификатор клиента и его устрйокста
- refresh_token - храним вместе с user_id, fingerprint, exp_at
1) В базе у нас есть таблица
user_id, fingerprint, refresh_token, exp_at
те строка соответствия id юзера, какого-то ключа устройства (фингерпринт) и сам рефреш-токен с датой валидности
2) злоумышленник украл наши токеныи шлет запрос на обновление токена (шлет ведь сразу оба токена?)
из access_token мы получаем (user_id + fingerprint), хоть он и просрочен
смотрим рефреш токен в базе
те ищем строку user_id + fingerprint + refresh_token
есть такая строка (логин нашего настоящего клиента ее туда поместил)
3) для злоумышленника генерируем новый аксес-токен и новый рефреш-токен обновляем в бд запись
user_id + fingerprint + refresh_token
злоумышленник всем этим прекрасно пользуется неограниченное время
4) наш пользователь аналогично пользуется своим аксес-токен, но он у него заканчивается и он шлет запрос обновления
5) мы в базе ищем его рефреш токен
user_id + fingerprint + refresh_token
и не находим, так как его обновил наш злоумышленник со соим фингерпринт, используя ранее украденные токены
6) соответсвенно клиента кидаем на авторизацию, он логинится и получает свои 2 токена, а злоумышленник продолжает пользоваться токенами. Приложение думает что просто клиент наш авторизован с 2ух устройств сразу и все в норме
Что-то я н понимаю, подскажите пожалуйста где ошибка?
V
если такой есть
V
или там все от рута должно ?)
V
а то группа то только чтение и выполнение
V
или группе разреши запись
SG
Я думаю что от 1000 должно
V
не знаком с такой штукой :D
SG
Хотя кто его знает
V
а тьфу, там же 1000 )
V
cat /etc/passwd|grep 1000
V
а ну скинь результат
V
айди то другой )
V
группа 1000 вродь, а юзер сам не 1000
SG
Эх... так это фигня какая-то =))