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

4.73K
.
¯\_(ツ)_/¯
Доброго времени суток Ждоновцы


Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
.
ஜ۩۞۩ ФкедaХ ۩۞۩ஜ
# PaRtiZzaN (23.12.2016 / 16:40)
Доброго времени суток Ждоновцы


Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
Чтобы их можно было скамуниздить
.
(\/)____o_O____(\/)
чтоб держать сессию открытой до нажатия кнопки выход. то есть если сессия вылетела, она востановится
.
# Koenig (23.12.2016 / 17:26)
чтоб держать сессию открытой до нажатия кнопки выход. то есть если сессия вылетела, она востановится
как то ты ппц обьяснил))
для идентификации пользователя в куках хранят его пароль и ид, иначе как узнать что это он, не заставляя его каждый раз вводить данные в форме авторизации?
.
юзерам не надо знать хеш своего пароля, да и id им ни к чему.
.
# Delphinum (23.12.2016 / 17:37)
юзерам не надо знать хеш своего пароля, да и id им ни к чему.
ну это уже ньюансы реализации) там может быть токен вместо ид и пароля, или еще что то
.
ramzes, ну ведь нюансы реализации могут быть ошибочны ) вот я и намекаю
.
Delphinum, идентификация по 1 ключу в любом случае менее надежна чем по двум, тут как не крути. особенно если обе строки публично недоступны (т.е. не ид который обычно легко узнать)
.
ramzes, не согласен. Если кто либо получить id сессии, то не важно, есть в сессии один только ид юзера или еще и пароль, доступ откроется.
.
AlkatraZ
╭∩╮ (`-`) ╭∩╮
На данный момент в JohnCMS система авторизации сильно устаревшая и нет смысла ее рассматривать.

По хорошему счету, логика авторизации (на примере MobiCMS) такова:

1) Клиент заходит на форму входа, вводит свой логин и пароль.
2) В базе данных ищется запись с введенным логином.
3) Если запись найдена, то хэш введенного в форму пароля, сверяется с имеющимся в базе (хэширование с солью). Далее пароль НИГДЕ не используется.
4) Если пароль совпадает, клиент считается авторизованным, ему генерируется временный токен (хэш строки из набора случайных символов и цифр).
5) Сгенерированный токен записывается в куки, сессию и специальную таблицу.

При повторном входе на сайт (если сессия уже протухла), токен из куков ищется в вышеуказанной таблице. Если токен есть и его время действия не прошло, клиент считается авторизованным.

Так, как токен генерируется от балды и не имеет никакого отношения к логину и паролю, вычислить какие-то данные по нему невозможно.

При желании, можно включать дополнительную защиту в виде привязки по IP (адрес тоже пишется вместе с токеном в вышеуказанную таблицу).

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