Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
Логика авторизации JohnCMS
5.47K
PaRtiZzaN
23 дек 2016 г., 16:40
¯\_(ツ)_/¯
Доброго времени суток Ждоновцы
Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
ФкедаХ
23 дек 2016 г., 16:42
ஜ۩۞۩ ФкедaХ ۩۞۩ஜ
# PaRtiZzaN (23.12.2016 / 16:40)Чтобы их можно было скамуниздить
Доброго времени суток Ждоновцы
Объясните кому не лень для меня логику авторизации, зачем пишется ид с паролем и в сессию и в куки?
Koenig
23 дек 2016 г., 17:26
(\/)____o_O____(\/)
чтоб держать сессию открытой до нажатия кнопки выход. то есть если сессия вылетела, она востановится
ramzes
23 дек 2016 г., 17:31
# Koenig (23.12.2016 / 17:26)как то ты ппц обьяснил))
чтоб держать сессию открытой до нажатия кнопки выход. то есть если сессия вылетела, она востановится
для идентификации пользователя в куках хранят его пароль и ид, иначе как узнать что это он, не заставляя его каждый раз вводить данные в форме авторизации?
Delphinum
23 дек 2016 г., 17:37
юзерам не надо знать хеш своего пароля, да и id им ни к чему.
ramzes
23 дек 2016 г., 17:42
# Delphinum (23.12.2016 / 17:37)ну это уже ньюансы реализации) там может быть токен вместо ид и пароля, или еще что то
юзерам не надо знать хеш своего пароля, да и id им ни к чему.
Delphinum
23 дек 2016 г., 17:43
ramzes, ну ведь нюансы реализации могут быть ошибочны ) вот я и намекаю
ramzes
23 дек 2016 г., 17:48
Delphinum, идентификация по 1 ключу в любом случае менее надежна чем по двум, тут как не крути. особенно если обе строки публично недоступны (т.е. не ид который обычно легко узнать)
Delphinum
23 дек 2016 г., 17:50
ramzes, не согласен. Если кто либо получить id сессии, то не важно, есть в сессии один только ид юзера или еще и пароль, доступ откроется.
AlkatraZ
23 дек 2016 г., 19:41
╭∩╮ (`-`) ╭∩╮
На данный момент в JohnCMS система авторизации сильно устаревшая и нет смысла ее рассматривать.
По хорошему счету, логика авторизации (на примере MobiCMS) такова:
1) Клиент заходит на форму входа, вводит свой логин и пароль.
2) В базе данных ищется запись с введенным логином.
3) Если запись найдена, то хэш введенного в форму пароля, сверяется с имеющимся в базе (хэширование с солью). Далее пароль НИГДЕ не используется.
4) Если пароль совпадает, клиент считается авторизованным, ему генерируется временный токен (хэш строки из набора случайных символов и цифр).
5) Сгенерированный токен записывается в куки, сессию и специальную таблицу.
При повторном входе на сайт (если сессия уже протухла), токен из куков ищется в вышеуказанной таблице. Если токен есть и его время действия не прошло, клиент считается авторизованным.
Так, как токен генерируется от балды и не имеет никакого отношения к логину и паролю, вычислить какие-то данные по нему невозможно.
При желании, можно включать дополнительную защиту в виде привязки по IP (адрес тоже пишется вместе с токеном в вышеуказанную таблицу).
По запросу в таблицу легко вычислить все активные сессии на данного пользователя и разлогинить по выбору любые из них. К примеру, был у кореша дома, залогинился на своем сайте и забыл потом разлогиниться. Куки и авторизация остались. Придя домой и зайдя в свой экаунт, легко удалить ненужные токены, тем самым аннулировав все левые авторизации.
По хорошему счету, логика авторизации (на примере MobiCMS) такова:
1) Клиент заходит на форму входа, вводит свой логин и пароль.
2) В базе данных ищется запись с введенным логином.
3) Если запись найдена, то хэш введенного в форму пароля, сверяется с имеющимся в базе (хэширование с солью). Далее пароль НИГДЕ не используется.
4) Если пароль совпадает, клиент считается авторизованным, ему генерируется временный токен (хэш строки из набора случайных символов и цифр).
5) Сгенерированный токен записывается в куки, сессию и специальную таблицу.
При повторном входе на сайт (если сессия уже протухла), токен из куков ищется в вышеуказанной таблице. Если токен есть и его время действия не прошло, клиент считается авторизованным.
Так, как токен генерируется от балды и не имеет никакого отношения к логину и паролю, вычислить какие-то данные по нему невозможно.
При желании, можно включать дополнительную защиту в виде привязки по IP (адрес тоже пишется вместе с токеном в вышеуказанную таблицу).
По запросу в таблицу легко вычислить все активные сессии на данного пользователя и разлогинить по выбору любые из них. К примеру, был у кореша дома, залогинился на своем сайте и забыл потом разлогиниться. Куки и авторизация остались. Придя домой и зайдя в свой экаунт, легко удалить ненужные токены, тем самым аннулировав все левые авторизации.
Всего: 185
© 2024, JohnCMS