Как сделать вечную авторизацию на сайте?

Question

[Владимир Шикльгрубер]

Привет. По колдовал я немного с php.ini. Теперь автоматом создаётся кука phpsessid. Как можно сделать что бы она сохранилась после закрытия браузера? (я хочу сделать вечную авторизацию как на всех популярных сайтах) Или как по другому сделать вечную авторизацию ? Разумеется что в куки я не буду писать ид пользователя :)

Answer 1

[Владимир Шикльгрубер]

я нагуглил только

// На всякий случай сменим папку для файлов сессии
ini_set('session.save_path', $_SERVER['DOCUMENT_ROOT'] .'/sessions/');
 
/**
*
*  Установка времении жизни сессии на 1 месяц.
*  Каждый раз при запуске файла эти значения будут переустанавливаться
*  так что сессия будет вечной ))
*
*/
ini_set('session.gc_maxlifetime', 3600*24*30);
ini_set('session.cookie_lifetime', 3600*24*30);

Comments

[Валерий Рябошапко]

А это, собственно, и есть ответ — поставить срок жизни кук как можно дольше, месяц или год. Можно несколько лет.

Answer 2

[trevoga_su]

Вечная авторизация - в куки кладем ID пользователя + md5(user_password . 'salt') на 10 лет.
в php проверяем (псевдокод):

$data = select * from user where id=$_COOKIE['id']

if ($data) {
   if (md5($data['user_password'] . 'salt') == $_COOKIE['hash']) {
       // авторизация
   }
}

если за вами не следят и не перехватывают ваш трафик - очень надежное и красивое решение.

Сессии - как видно из названия - нужны не для этого. На phpfaq.ru об этом хорошо написано. Устанавливать длительное время жизни сессионной кукуи - не правильно совершенно.

Comments

[Константин]

а можете поделиться соображениями на тему "не правильно совершенно"?

[Stepan Yudin]

и мне интересно

[XpeH Петрович]

на phpfaq и не такого напишут. это ж php "коммьюнити", ага. да, Вы к тому же не забывайте что у многих пользователей куки автоматически чистятся, и все чаще, чем раньше

[trevoga_su]

XpeH Петрович: пхпфак - очень авторитетный ресурс.

unity_ultra_hardcore: Степан Юдин:

http://hghltd.yandex.net/yandbtm?fmode=inject&url=...

Очень важно понимать, для чего сессии стоит использовать, а для чего - нет.

Во-первых, помните, что сессии можно применять только тогда, когда они нужны самому пользователю, а не для того, чтобы чинить ему препятствия. Ведь он в любой момент может избавиться от идентификатора!
Скажем, при проверке на то, что заполняет форму человек, а не скрипт, пользователь сам заинтересован в том, чтобы сессия работала - иначе он не сможет отправить форму! А вот для ограничения количества запросов к скрипту сессия уже не годится - злонамеренный скрипт просто не будет возвращать идентификатор.

Во-вторых. Важно четко себе представлять тот факт, что сессия - это сеанс работы с сайтом, так как его понимает человек. Пришел, поработал, закрыл браузер - сессия завершилась. Как сеанс в кино. Хочешь посмотреть еще один – покупай новый билет. Стартуй новый сеанс. Этому есть и техническое объяснение. Гарантированно механизм сессий работает только именно до закрытия браузера. Ведь у клиента могут не работать куки, а в этом случае, естественно, все дополненные идентификатором ссылки пропадут с его закрытием.
Правда, сессия может пропасть и без закрытия браузера. В силу ограничений, рассмотренных в самом главном разделе этого FAQ, механизм сессий не может определить тот момент, когда пользователь закрыл браузер. Для этого используется таймаут – заранее определенное время, по истечении которого мы считаем, что пользователь ушел с сайта. По умолчанию этот параметр равен 24 минутам.
Если вы хотите сохранять пользовательскую информацию на более длительный срок, то используйте куки и, если надо - базу данных на сервере. В частности, именно так работают все популярные системы авторизации:
- по факту идентификации пользователя стартует сессия и признак авторизованности передается в ней.
- Если надо "запомнить" пользователя, то ему ставится кука, его идентифицирующая.
- При следующем заходе пользователя на сайт, для того, чтобы авторизоваться, он должен либо ввести пароль, либо система сама его опознает по поставленной ранее куке, и стартует сессию. Новую сессию, а не продолжая старую.

В-третьих, не стоит стартовать сессии без разбору, каждому входящему на сайт. Это создаст совершенно лишнюю нагрузку. Не используйте сессии по пустякам – к примеру, в счетчиках. То, что спайлог называет сессиями, считается, конечно же, на основе статистики заходов, а не с помощью механизма сессий, аналогичного пхп-шному.
К тому же, возьмем поисковик, который индексирует ваш сайт. Если поисковый робот не поддерживает куки, то пхп по умолчанию будет поставлять к ссылкам PHPSESSID, что - согласистесь - может не сильно понравится поисковику, который, по слухам, и так-то динамические ссылки не жалует, а тут вообще при каждом заходе - новый адрес!

[Владимир Шикльгрубер]

как то стремно так пароль хешировать)) ДА и не безопасно.. украли куки и получили полный доступ над аком

[trevoga_su]

Владимир Шикльгрубер: пароль сохраняется в мд5, и при установке в куку шифруется уже хэш от пароля с солью.

украсть? ну да, можно украсть. тогда https всякие используйте.

[Владимир Шикльгрубер]

trevoga_su: я по реальному паролю прошелся трижды sha512 и потом уже этот хеш кинул в кук. Реальный пароль с солью) очень большой солью)

Answer 3

[MKMatriX]

Вообще "вечную" авторизацию можно сделать храня ее в localStorage) Т.е. если куки истекли, а в локал сторадже есть данные для авторизации, то отправляем запрос, и получаем куки с нужной фигней. Из дополнительных плюшек - можно ставить короткое время жизни кук, ддосить свой серв, зато быть защищенным от действий мамкиных хацкеров ворующих куки. В теории можно сделать что в куки идет вообще какая-то дополнительная соль, работающая короткое время)