Comments 22
Меня интересует не конкретная реализация, а сама идея.
Я правильно понимаю, что при любом обращении юзера, сервер на своей стороне перезаписывает в свое хранилище обновленный токен?
Какую задачу решают таким действием? Почему нельзя продолжать хранить тот же токен до истечения его срока?
Я правильно понимаю, что при любом обращении юзера, сервер на своей стороне перезаписывает в свое хранилище обновленный токен?
Какую задачу решают таким действием? Почему нельзя продолжать хранить тот же токен до истечения его срока?
Если я верно понял, в случае если пользователь в момент любого запроса потеряет соединение, то токен обновился, но пользователь его не получит. Сильно критично для мобильных устройств, где сеть может прыгать из 3G в 2G, а то и полностью теряться несколько раз в минуту.
> в момент запроса потеряет соединение.
если честно я не понял.
юзер может сделать запрос в любое время с любого ip, и сопроводить его своим токеном.
я пытаюсь понять суть действий на стороне сервера.
зачем на сервере при каждом запросе юзера обновляется токен. какая цель стоит за этим действием?
если честно я не понял.
юзер может сделать запрос в любое время с любого ip, и сопроводить его своим токеном.
я пытаюсь понять суть действий на стороне сервера.
зачем на сервере при каждом запросе юзера обновляется токен. какая цель стоит за этим действием?
Токен важен будет только при первом запросе, затем уже сработает сессия. Так что такая ситуация как вы описали возможна только при первом запросе. Если критично, то ето всегда можно отключить флажком 'refresh' в конфиге
Если перехватить постоянный токен то его можно будет использовать до окончание срока. Если же перехватить тако одиночный токен то с ним уже ничего сделать не можно
а, т.е. у пользователя токен тоже меняется.
тогда вопрос отпадает.
тогда вопрос отпадает.
что-то мне подсказывает, что при такой схеме обновления токенов, юзера у которых нестабильное соединение, постоянно будут терять авторизацию.
сервер токен поменяет, а юзер не получит новый токен в ответ из-за плохой связи, и в следующий раз пойдет со старым, ведь другого токена и нет.
такое поведение будет вызвать обоснованную критику у пользователей к сервису.
я бы менял токен не с каждым обращением, а с привязкой к периоду. скажем 5 мин действует один токен, позже будет выдан новый. в разы уменьшит зависимость от сбоев.
сервер токен поменяет, а юзер не получит новый токен в ответ из-за плохой связи, и в следующий раз пойдет со старым, ведь другого токена и нет.
такое поведение будет вызвать обоснованную критику у пользователей к сервису.
я бы менял токен не с каждым обращением, а с привязкой к периоду. скажем 5 мин действует один токен, позже будет выдан новый. в разы уменьшит зависимость от сбоев.
я уже писал выше чуть что токен важен лишь при первом запросе, после этого юзеру создастся сессия которая работает пока бразуер не закрыть.
То есть если у нас в качестве клиента не браузер — компонент либо бесполезен либо нам приходится хэндлить еще и куки/сессии, и, если конечно сессии не хранятся в каком-нибудь кластере в редис или еще где, горизонтальное масштабирование сильно усложняется… так?
Не совсем понял, компонент http авторизации конечно же подразумевает браузер. Для провайдера авторизации по паролю канал совсем не важен.
Я так понял у вас ввиду авторизация например токеном каким то? Если да, то придется написать свой првайдер ( на пару строк буквально, так как можно использовать уже готовую логику с токенами)
Я так понял у вас ввиду авторизация например токеном каким то? Если да, то придется написать свой првайдер ( на пару строк буквально, так как можно использовать уже готовую логику с токенами)
Понятно. Вообще восхищаюсь вашим энтузиазмом в написании велосипедов. Есть ще symfony/security, куча готовых библиотек и прочее… почему бы не потратить ментальную энергию на контрибьюцию туда, улучшить уже имеющиеся решения… Хотя пожалуй это риторический вопрос.
ну например Symfony2 по дефолту в кук пишет хеш пароля с солью, что намного меньше безопасно и поддается брутфорсу. Они сами рекомендуют использовать токен сервис из Доктрині например. А в пиксе безопасно из коробки
не из доктрины, а идущий в комплекте с симфони фулстэк фреймворком DoctrineTokenProvider. По умолчанию используется единственный доступный способ, ибо symfony/security ничего не знает о том как хранить данные еще как-то. Все отдается на откуп разработчика. И я не считаю это недостатком конкретно симфони секьюрити, а скорее недостаток дефолтной конфигурации самой симфони.
Ну вот теперь у вас есть выбор получить те же токены только без доктрины в проекте. Плюс в симфони токены тесно связаны как раз с «remember me» функционалом ( даже в том неймспейсе лежат), а в пиксе токены отдельная подсистема которую можно где-нибудь использовать
Потому что в Symfony токены нужны исключительно для того что бы привязать сессию в контексте remember me и только в контексте не stateless реализации.
Опять же, все это решается введением своих провайдеров. Я это к тому что бы делать разработку полностью с нуля можно было бы реализовать просто парочку интерфейсов из symfony/security и тд. Symfony/security не сказать что идеален, там много стремных моментов, он сложный… но для такой критической вещи как безопасность, управление правами и т.д. лучше иметь одну-две хороших реализации нежели тысячу так себе. Поддерживать один критически важный компонент намного проще чем два или три.
Просто по фану — да, клево, и реализация ничего так, но использовать ее в живых проектах как-то стремно.
Опять же, все это решается введением своих провайдеров. Я это к тому что бы делать разработку полностью с нуля можно было бы реализовать просто парочку интерфейсов из symfony/security и тд. Symfony/security не сказать что идеален, там много стремных моментов, он сложный… но для такой критической вещи как безопасность, управление правами и т.д. лучше иметь одну-две хороших реализации нежели тысячу так себе. Поддерживать один критически важный компонент намного проще чем два или три.
Просто по фану — да, клево, и реализация ничего так, но использовать ее в живых проектах как-то стремно.
использование password_hash() из PHP7
Наверное, имелось ввиду 5.5. Для более ранних версий существует fallback от Энтони, автора rfc password_hash.
Прошу прощение, не заметил, что уже задействована.
Спасибо, да в статье ошибся, уже поправил =)
Sign up to leave a comment.
Безопасная авторизация с PHPixie 3