Как правильно реализовать сессии при авторизции
- Автор темы m1ko
- Дата начала
ponchic
Писатель
- Регистрация
- 8 Авг 2014
- Сообщения
- 1
- Реакции
- 1
если пароль будет зашифрован md5(base64(md5())); то безопасно.
И зачем сессии? Проще сделать в базе данных в таблице с пользователями ещё две колонки (session, datesession)
Когда пользователь зайдёт, ему сгенериться сессия, и вместе с датой (в мускульном запросе NOW()) запишется в бд, а что бы значения наших полей удалялись можно в крон или планеровщик задач MySql добавить удаление их.
И зачем сессии? Проще сделать в базе данных в таблице с пользователями ещё две колонки (session, datesession)
Когда пользователь зайдёт, ему сгенериться сессия, и вместе с датой (в мускульном запросе NOW()) запишется в бд, а что бы значения наших полей удалялись можно в крон или планеровщик задач MySql добавить удаление их.
Q_BASIC
Хранитель порядка
- Регистрация
- 30 Ноя 2013
- Сообщения
- 516
- Реакции
- 1.240
Зачем еще крон? Добавить поле time и туда записывать UNIX time. Потом при получении сессии добавить:
Код:
WHERE `time`>".time()-86400."
vitbsd
Постоялец
- Регистрация
- 26 Ноя 2009
- Сообщения
- 115
- Реакции
- 82
Я сейчас вот тоже пытаюсь реализовать авторизацию правильную. Мысль есть такая, не хранить пароль вообще в сессиях и куках и т.д Генерировать некий ключ, по которому уже искать пользователя в БД. Пароль паролем а вот ВПИСАТЬ куда нибудь уникальный кусочек в куку и играться с ним. Ну и естественно при неверно маске IP - на вход с удалением кук и перегенерированием этого кусочека и т.д
m1ko
Создатель
- Регистрация
- 15 Авг 2010
- Сообщения
- 42
- Реакции
- 3
- Автор темы
- #6
проверка не по маске а по 1 ip если меняется что-то, то не пускать
+ хочу сделать мультисессии как в вк, если есть желание, можем попробовать вместе сделать одно дело.
Хотя нет не по ip, но и не по маске.. как с телефонным интернетом дела обстоят, хаос начнется походу..
Последнее редактирование:
artxaker
Постоялец
- Регистрация
- 25 Авг 2009
- Сообщения
- 48
- Реакции
- 38
Хранить пароль в сессии или в куке??
Вобшем, мой подход такой.
таблица авторизации
ид.,ид ползователя, токен, номер сессии(случайный уникалный сгенерированный номер), активен до, активен(труе,фолсе),агент(браузер), ип(айпи), тиместамп(последную дату активности)
Если аунтификация выполнена.
Генеруется "номер сессии случайный код" етот код хранится в таблице авторизации и в куке, так мы избегаем хранения ид или пароль пользователя в куке или в сесии, генерируем токен мд5(номер сессии + ид пользователя + агент(браузер) + ип(айпи) + соль) и храним его в базе, также храним браузер "активност до" дата по стандарту мускула, "актиен" на 1, и "тиместамп" чтоб узнать пользователь офлайн или онлайн.
Проверка на куки.
Если токен не совподает с имееюшим в базе( и или активен = 0,или активность до меньше чемтекушяя дата) то чтото изменилось может ип может браузер то не даем ему доступа
и удаляем все куки у етого пользователя а в логе если установлен уведомляем пользователя о вторжении(если токен не совпал)
Вобшем, мой подход такой.
таблица авторизации
ид.,ид ползователя, токен, номер сессии(случайный уникалный сгенерированный номер), активен до, активен(труе,фолсе),агент(браузер), ип(айпи), тиместамп(последную дату активности)
Если аунтификация выполнена.
Генеруется "номер сессии случайный код" етот код хранится в таблице авторизации и в куке, так мы избегаем хранения ид или пароль пользователя в куке или в сесии, генерируем токен мд5(номер сессии + ид пользователя + агент(браузер) + ип(айпи) + соль) и храним его в базе, также храним браузер "активност до" дата по стандарту мускула, "актиен" на 1, и "тиместамп" чтоб узнать пользователь офлайн или онлайн.
Проверка на куки.
Если токен не совподает с имееюшим в базе( и или активен = 0,или активность до меньше чемтекушяя дата) то чтото изменилось может ип может браузер то не даем ему доступа
и удаляем все куки у етого пользователя а в логе если установлен уведомляем пользователя о вторжении(если токен не совпал)
SaVage4Pro
Писатель
- Регистрация
- 2 Июн 2015
- Сообщения
- 2
- Реакции
- 2
очевидно, имеется в виду хранение в куке не токена, а id сессии, "номер сессии случайный код"
собственно встречный вопрос - зачем вообще хранить пароль где-то еще, кроме основного места его хранения в зашифрованном виде?
он нужен только один раз - для авторизации
вся инфа, которая будет использоваться после авторизации, хранится в сессии
в куке должен хранится только идентификатор сессии, притом данная кука должна быть HttpOnly
удобоваримые варианты с токенами без фанатизма:
1. генерить одноразовые токены при загрузке страницы и проверять при обработке post`а, чтобы быть немного более уверенным, что данные пришли именно с формы на сайте (в которую и добавляется временный токен), а не откуда попало, держать же их в БД, которая позволяет много писать и много читать
2. генерить постоянные (условно) токены, которые записывать в саму сессию один раз при успешной авторизации, а в дальнейшем нам нужно будет проверить записанный в сессию токен с генерируемым проверочным кодом при каждом post-запросе (или даже при каждой загрузке страницы), который составляется так же, как и токен, на основе данных, переданных клиентом, включая браузер и ip-адрес. В случае, если что-то из этих данных поменялось, проверочный код не совпадет с токеном, записанным в сессию и клиенту надо делать перелогин, неважно кто это - настоящий ли пользователь, но зашел из другого браузера или его телефон перескочил на другую точку доступа, или же это злая собака, пытающаяся отправить форму со своей машинки, используя стыренные куки, можно до кучи такой токен сделать и временным, или писать в него какую-нибудь рандомную временную куку, которую обновлять при каждой успешной загрузке страницы
фантазия ограничивается только возможностями сервера и его предполагаемой и реальной нагрузкой