Логика авторизации JohnCMS

AlkatraZ, Ну это лучше чем было

А зачем токен и куки, если есть ид юзера и сессия?

# PaRtiZzaN (23.12.2016 / 19:43)
AlkatraZ, Ну это лучше чем было

Это не просто "лучше", а для однофакторной (классической) авторизации - наилучший вариант.

# Delphinum (23.12.2016 / 19:52)
А зачем токен и куки, если есть ид юзера и сессия?

Сессия протухнет и что тогда?
А ID юзера нам не нужен, токен однозначно определяет юзера

Как сессия протухнет, так и авторизация закончится.
Ид юзера тоже однозначно его идентифицирует, зачем еще один однозначный токен? )

# Delphinum (23.12.2016 / 19:54)
Как сессия протухнет, так и авторизация закончится.
Ид юзера тоже однозначно его идентифицирует, зачем еще один однозначный токен? )

А вот это не надо, особенно для мобильной сферы.
По-умолчанию в РНР время жизни сессии то ли час, то ли не помню. Каждый день вводить авторизацию - замучаешься.

А так, ты сам можешь устанавливать (как на некоторых форумах) на сколько тебя запомнить, включая "навсегда". То есть, пока живы куки и пока ты не разлогинился, сможешь спокойно заходить. Это удобство для клиента.

Альк, у нас клиенты хоть на всю жизнь могут в авторизованных ходить. Все так же определяется временем жизни кукисов (в нашем случае редиса).

# Delphinum (23.12.2016 / 20:06)
Альк, у нас клиенты хоть на всю жизнь могут в авторизованных ходить. Все так же определяется временем жизни кукисов

Да не имеет значения.
Хэш сессии - это тот же самый хэш, что я генерирую. Просто я не насилую сессии, а использую отдельную таблицу для токенов.

AlkatraZ, в том то и соль, что при наличии аналога ты зачем то генеришь свой SSID. Не велосипедь )

# Delphinum (23.12.2016 / 19:54)
Как сессия протухнет, так и авторизация закончится.
Ид юзера тоже однозначно его идентифицирует, зачем еще один однозначный токен? )

И что? Вводить пароль опять? Это худший из вариантов