xmoonlight, я пытаюсь подойти со стороны использования этой технологии для spa-сайтов.
Я так понял, что AuthHash хранится не в localStorage, и сделал вывод, что он хранится в куках.
Куки - https://ru.wikipedia.org/wiki/Cookie
Что такое идентификатор устройства я пытался понять несколько сообщений тому назад. Чтобы не засыпать вопросами для себя сделал вывод, что это уникальная строка, идентифицирующая конкретное устройство (браузер в общем случае). Как его получить - мне тоже очень интересно)
xmoonlight,
1. Потому что с помощью javascript не получить нормальный deviceID.
С мобильного интернета перешёл на вай-фай и подсеть уже другая.
Допустим, злоумышленник угнал таки AuthHash. Он получает полный доступ?
2.
Такая же ситуация возможна? И токен в обоих случаях протух и его надо обновить.
Без реализации такое сложно обсуждать, и я сомневаюсь, что такое можно нормально реализовать)
В общем, если я хоть что-то правильно понял, то это что-то вроде jwt, и моё мнение на его счет не изменилось, несмотря на то, что я бы сильно этого хотел)
И отдельное спасибо за потраченное время :)
1. Т.е. для использования с мобильным интернетом данный способ не подойдёт? Это если использовать IP. Если рассматривать spa, то непонятно, как получать clientID. Если
2. А если ответ с новым ключом ещё не получен? В общем, на реализацию этого пункта я бы с удовольствием посмотрел. Это одна из причин, почему было решено оказаться от jwt.
6. Т.е. мало живёт токен, если я правильно понял. Это ещё один гвоздик к размышлениям из пункта два.
xmoonlight,
1. Идея хранения AuthHash на первый взгляд выглядит интересной. Но что если злоумышленник уведет AuthHash к себе? Он получит полный доступ до тех пор, пока пользователь не поменяет пароль? При этом пользователь даже не узнает, что кто-то сидит в его учетке.
2. Какой ключ может быть отозван на сервере? Пытаюсь понять, как мы проверяем AuthHash.
3. А если последующий запрос будет подписан старым токеном? Клиент получит ошибку и заново авторизуется по AuthHash?
6. Сколько живёт токен сессии? Его можно отозвать?
xmoonlight, ну вот первый пункт из ответа ясен - отправляем логин-пароль, получаем токен. Готово, на клиенте есть токен, так?
Дальше в пункте 2 написано, что надо что-то отхешировать, используя timestamp и random. Это на клиенте происходит?
Или имеет ввиду как раз пункт два с картинка? Если так, то в ссылке из ответа, логика работы rest расписана очень коряво.
Чет непонятно ничего. Когда сервер может вернуть chain-token?
Пункт номер 2 тоже не понял - нужно что-то хэшировать на клиенте? Использую timestamp? Откуда? С клиента?
Можно даже на примере попробовать. Вот у меня есть token: qwefasf, я хочу получить данные /get/books. Как будет выглядеть мой запрос?
>Если приходит новый токен, то необходимо подписывать новый запрос к API уже этим новым токеном.
А если в это время уже идёт получение данных вторым запросом старым токеном, а первый запрос уже выполнился и прислал новый токен.
Что за прозрачным режим получения токена? Предлагаешь на клиенте хранить логин-пароль пользователя?
Пробовал добавлять им data-* атрибуты и поворачивать через transform: rotate(data-rotate), активному ноль, верхнему 120, нижнему 240 и подменять их по клику, но так очень криво все работает
Всё нормально должно работать, инфа 100%. Где пример кода на codepen.io?
https://youtu.be/YP3lpPTKw1w