Сабж.
После логина клиент имеет токен, через который грабит api. Данные о пользователе хранятся на клиенте некоторое время.
Проблема: что делать если сервер изменил данные о клиенте (user_name например), а клиент об этом еще не догадывается?
Думал что-то в этом роде.
Завести промежуточную таблицу в которой хранить "сброшенные токены", хранить не более определенного времени. После изменения профиля, сбрасывать основной ("активный") токен в эту промежуточную таблицу.
Следовательно, при новом запросе, сервер не обнаружит "активного" токена, нужно предложить посмотреть еще и в промежуточную таблицу, если там токен есть, отправить клиенту новую инфу с предварительно сгенерированным токеном. Если токена нету даже в промежутке, или истек срок хранения промежуточного токена, отправлять юзера на релогин.
Владислав Турчинский: Просто я против что бы без ведома пользователя что-то менять, тем более критические данные.... Опять же если есть механизм протухания токена и его восстановления, то зачем что то изобретать? если это частая ситуация значит надо задуматься, что я делаю не так.... имхо как то так... ну опять же можно сделать что если поменялось что то критическое.. то ставить некую метку и при запросе посылать эти данные тоже.. а на клиенте менять, но опять это же кажды раз проверять надо.. спрашивается а зачем? :)
Владислав Турчинский: Да я понимаю, что это можно все делать, и сами делали это... но тут прозвучало чуть другое )
лучше в бекграунде пароль ему поменять и пусть запрашивает его заново.. ну а чего ))))
Все на много проще. Сервер один, клиентов много: приложение на iPad, iPhone и Web-site. По этому, клиент может не знать, что "критичные" данные были изменены, т.к., были они изменены на другом клиенте.
"Опять же если есть механизм протухания токена и его восстановления, то зачем что то изобретать?" – механизма нету, нужно организовать. Я так понимаю, вы о том, что я описал? Ита схема мне нравится, но в ней не уверен. Хочу услышать мнения экспертов.
Средний
Средний