Как лучше проверять авторизован ли пользователь?

Question

[Banny_Boom]

Делаю так:
Авторизовался:
В сессию - 'logined' - true
в куки:
id
hash
Планирую создать CRON, который каждые 5 минут будет проверять авторизован ли пользователь или нет, или подменили что-то... (Сверяться с бд и т.д)

Не сравнивать же все с бд при каждом действии/переходе...
Так что проверяю если SESSION 'logined' === true
То все хорошо...

Подскажите, как это делайте вы?

Answer 1

[evnuh]

При чём здесь куки? У вас есть сессии, вот в них всё и пишите. На успешном логине записываете logged_in = true, можете ip записать в сессию для пущей безопасности. На каждом запросе смотрите в эти самые сессии и сверяете ip запроса с ip в сессии, если сменился разлогиниваете.

Ваши поделки с хешами уже решены в сессиях. И cron-a никакого не надо, выставляете таймаут сессиям который хотите и сессионная кука сама удалится.

По секрету скажу, что сессии по дефолту хранятся в файлах на жестком диске, поэтому выборка данных из сессии будет не быстрее, чем выборка данных из БД. Поэтому не стоит пытаться оптимизировать то, в чём не разбираетесь.

Comments

[Александр Таратин]

>сверяете ip запроса с ip в сессии, если сменился разлогиниваете.
Некоторые пользователи вас возненавидят. Лучше чекать принадлежность ip одному провайдеру или географическому региону.

[Banny_Boom]

это что-то типа "Запомнить меня"
В куки и пишу хэш и id

[evnuh]

Banny_Boom: вы читали мой ответ? перечитайте, вы его не поняли. Забудьте про куки, у вас есть сессии.

[Banny_Boom]

evnuh: Перечитал, мб снова не понял, но думаю вы меня тоже не поняли..
В куки я записал Хэш(он сравнивается с хэшэм в бд)
и ID пользователя.

Если это все делать только на сессиях, то если закрыть браузер то, придется снова авторизовываться, а тут идет проверка по кукам, и в сессию loggined_in - true

[evnuh]

Banny_Boom: так вы не умеете с сессиями работать!
Ещё раз говорю - забудьте про куки и прочитайте вот www.php.net/manual/en/session.configuration.php#in... и вот www.php.net/manual/en/function.session-set-cookie-...

[Banny_Boom]

evnuh: Хорошо, поставил я таймаут сессии 24 минуты, прошло, сессия удалилась, откуда взять данные чтобы снова проверить не подменили ли ничего..
Например не захожу неделю, сессия удалилась, но мне нужно чтобы пользователю не приходилось каждый раз вводить свой пароль, только если что-то не прошло по проверке..

Извеняюсь за мою тупость, но как-то я покачто не особо понимаю :c

[Станислав Макаров]

@Banny_Boom
> сессия удалилась
> чтобы пользователю не приходилось
значит не должна удаляться)

[Banny_Boom]

Станислав Макаров: с этого все и началось, если она не будет удаляться, то при каждом действии/переходе на страницу, я должен проверять наличие сессии и session loggined_in === true

Или я кажется понял, установить время жизни только для loggined_in ?
А остальным нет?

[Станислав Макаров]

Banny_Boom
> то при каждом действии/переходе на страницу, я должен проверять наличие сессии и session loggined_in === true
почему вы видите в этом проблему? конкретные причины. У вас 5000 запросов в секунду?

[Станислав Макаров]

Banny_Boom вот посмотрите, даже сама функция start_session() спроектирована так, чтобы автоматически поднимать старую/создавать новую сессию, вам даже заморачиваться с этим не надо

[evnuh]

Banny_Boom: объясните, почему вы не желаете на каждом запросе читать сессии? вы же даже не знаете, как они работают, но четко решили для себя, что это будет медленно?) делайте как все, не ошибетёсь, вы же только учитесь.

[Banny_Boom]

evnuh: Хорошо, спасибо за помощь)

[Николай]

evnuh

По секрету скажу, что сессии по дефолту хранятся в файлах на жестком диске, поэтому выборка данных из сессии будет не быстрее, чем выборка данных из БД.

- Понимаю, что вопрос был задан давно и НЕ об этом, но не смог пройти мимо. Львиная доля в ускорении сайта заключается в кешировании того или иного. Кеширование данных в базе может быть настроено таким образом, что все, необходимые Вам данные будут лежать либо в кеше, либо в индексах, т.е. в оперативке, и доступ к ним не потребует обращения к диску.
Сплошь и рядом встречается архитектура, при которой БД и скрипты бекенда разнесены по физически разным серверам. В этом случае даже если база вся целиком висит в кеше, но есть лаг на сети, скорость доступа к локальным ресурсам (файлам сессии) обойдёт "долгий" запрос к удалённому серверу.
В то же время ОС (тот же линукс) из коробки умеет кешировать файлы, доступ к которым осуществляется достаточно часто. Таким образом, если углубиться в администрирование своего сервера и настроить принудительное кеширование файлов с сессиями, опять получится хранить/брать данные из ОЗУ, что несоизмеримо быстрее традиционных дисковых операций.
Следующий момент (дополняющий предыдущий) это всевозможные tmpfs и прочие файловые системы, "размечающие" область в оперативке и позволяющие работать с ней как с диском. Если Вы изначально храните Ваши сессии в такой системе - опять-таки получаете бонус по скорости обработки данных.

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

Answer 2

[Виталий Инчин ☢]

Не сравнивать же все с бд при каждом действии/переходе...

Чей-та? Это вполне нормально, если действие от "подмененного" пользователя может что-то за собой повлечь. А такие серьезные проекты, как Вконтакте, так вообще каждые 10 секунд проверки выполняют.

Comments

[Banny_Boom]

выходит при каждом переходе/действии, я должен проверять все сравнивать с бд ?

[Виталий Инчин ☢]

Banny_Boom: комментарии, изменения данных, посты,что у вас там еще - да, а простое перемещение по сайту - без особой надобности.

Answer 3

[Stalker_RED]

В куках только идентификатор сессии. Писать туда userId или логин слишком рискованно, т.к. пользователь легко может их модифицировать.
Проверять авторизацию по таймеру - излишне, имхо. Достаточно ограничить время жизни сессии какими-то разумными рамками (по умолчанию 24 минуты).

Comments

[Banny_Boom]

это что-то типа "Запомнить меня"
В куки и пишу хэш и id

[Stalker_RED]

Banny_Boom: Вы понимаете как работает php session? Если да, то чем выигрывает ваш метод?

[Banny_Boom]

Stalker_RED: Примерно да...
Например если я все запишу в сессии, а не куки, то закрыв браузер придется снова авторизовываться, а тут по кукам сверит все, если все хорошо, то идем дальше, как-то так...

[Stalker_RED]

Banny_Boom: Почему придется? И кукам и сессии можно задать время жизни. Поставьте лет сто, и сессия не пропадет.

[Banny_Boom]

Stalker_RED: Я думал что сессия удаляется при закрытии браузера, и живет на стороне сервера

[Stalker_RED]

Banny_Boom: А откуда сервер вообще может знать закрыт браузер или нет?

[Alexander Litvinenko]

Banny_Boom: Сессия живет на сервере, в браузере записан куки с ИД сессии. Так как никто из клиентов не знает чужие сессион ид, то это безопасно.

Answer 4

[Dmitriy Mozgovoy]

Ну если решили собственный механизм авторизации на куках, то я обычно, если не для Пентагона пишу, делаю так:
Храню в куках userid и hash сгенерированной сессии
На сервере проверяю в какой-нить функции типа enterSession наличие куки и если есть- ищу по куках сессию для пользователя userid и сходится ли IP на которую он открыт с тем, с которого пытаются сделать запрос. Если все ОК заполняю какой нить $CURRENT_USER массив c основной инфой, иначе =null; Тогда, если $CURRENT_USER!=null значит авторизован.
Сессии храню в таблицах в озу в Nosql. После, обычно, 60 мин бездействия, сессию закрываю. Для особо критичных действий - прошу указать текущий пароль...
собственно не многим отличается от сесcий php...