Меню
Что нового?

Сохранение авторизации

fire-one

Новичок
Сохранение авторизации

Доброго времени суток

На своем сайте я осуществляю авторизацию пользователей с помощью сессий (сохраняю в переменных имя пользователя и пароль и результат авторизации 1/0)
Сессия обнуляется если не обновлять страницы некоторое время (кстати, какое ?)
Чтобы сохранять авторизацию на более длительные сроки чем нужно пользоваться ?
Куки ?
 

Alexandre

PHPПенсионер
Сессия обнуляется если не обновлять страницы некоторое время (кстати, какое ?)
Нажмите для раскрытия...
см php.ini или phpinfo()
Чтобы сохранять авторизацию на более длительные сроки чем нужно пользоваться ?
Нажмите для раскрытия...
можно сессии хранить в БД, тогда необходимо написать свой обработчик сессий
но это чревато тем, что тебе нужно будет самому убивать устаревшие данные.
Куки ?
Нажмите для раскрытия...
можешь использовать куки,
но, не забывай, что идентификатор сессии уже сидит в куке.
в куку можно запихнуть до 2к информации.
 

fire-one

Новичок
я правильно механизм понял:
1. Пользователь авторизовался и нажал галочку "хранить", данные занеслись в куки
2. Пользователь ушел, сессия закончилась, но куки остались.
3. Когда на сайт заходит неавторизованный пользователь проверяется наличие данных в куки. и если данные верны - авторизуем.

правильно ?
 
rotoZOOM

rotoZOOM

ACM maniac
fire-one Насчет куки. Продумай такие моменты:
1. Куку утащили с компа на другой.
2. За этот комп сел другой пользователь и вошел на твой сайт
под чужим именем.
 
zerkms

zerkms

TDD infected
Команда форума
но это чревато тем, что тебе нужно будет самому убивать устаревшие данные.
Нажмите для раскрытия...
нет, не чревато. при реализации своего контейнера сессий - ты обязан реализовать и gc, который будет запускаться автоматом, с помощью встроенных механизмов с заданной вероятностью

fire-one
сделай отдельную таблу
unique_hash | user_id | ip | useragent
при входе пользователя на сайт - смотри есть ли в куках unique_cookie, если есть - ищи её значение в табле в поле unique_hash. если есть такая + ip + UA + ещё что хочешь совпадают - то это user_id
хэш можно генерить как угодно, хоть md5(microtime(true))

-~{}~ 16.02.08 15:02:

1. Куку утащили с компа на другой.
2. За этот комп сел другой пользователь и вошел на твой сайт
Нажмите для раскрытия...
3. за этот комп сел другой пользователь и поставил кейлоггер => любая защита потерпит фиаско.
не стоит за пользователя пытаться решать его проблемы
 

Hunterex

Новичок
zerkms зачем делать отдельную таблицу, когда к примеру можно сделать отдельное поле в таблице пользователей? и туда заносить некий хеш на основе useragent + ip
и если текущий хеш не соответствует тому с которым пришел, то не активировать авторизацию?
 
baev

baev

‹°°¬•
Команда форума
Hunterex, сессионные данные хранятся ограниченное время (и не для всех пользователей).
Если на форуме, к примеру, всех зарегистрированных пользователей больше 5000, а активных участников около 200, то нет смысла при каждом входе активного участника перебирать таблицу со всеми.
 
zerkms

zerkms

TDD infected
Команда форума
и туда заносить некий хеш на основе useragent + ip
и если текущий хеш не соответствует тому с которым пришел, то не активировать авторизацию?
Нажмите для раскрытия...
бугого... насколько ты считаешь комбинацию UA + ip уникальной?
а если человек ходит на ресурс с работы и из дома, то на работе (или дома) автоматического "узнавания" уже не будет? ;)
 

Hunterex

Новичок
baev я не пояснил, имел в виду куки.

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

zerkms

TDD infected
Команда форума
Hunterex
извини конечно, но ты предлагал исключить отдельную таблицу, и хранить всё вместе...
по факту же - твой вариант по "безопасности" ничем не лучше (а если точнее - то абсолютно аналогичен) тому, который предложил я

повторю ещё раз: некоторую долю уверенности может добавить ip + UA (ну и например HTTP_ACCEPT_CHARSET)

перечитай свои и мои посты и переставай уже тупить
 

Hunterex

Новичок
zerkms
а я и не говорил что мой вариант безопаснее, просто зачем делать отдельную таблицу
 
zerkms

zerkms

TDD infected
Команда форума
Hunterex
затем, что у человека бывает >1 постоянного компьютера, браузера и интернет провайдера
 

zibox86

Новичок
Напиши JavaScript которы через указанное время будет вызывать функцию в php на уничтожение session!
 
Войдите или зарегистрируйтесь для ответа.
Сверху