Запутался с cookie и сессиями

[Ivanov]

Запутался с cookie и сессиями

Что-то я начитался разных статей, сообщений на форуме и запутался совсем.

У меня данные о пользователях хранятся в БД, при авторизации пользователя переменная ok становится истина и заполняются переменные, которые характеризуют права пользователя (доступ к разделам и пр.). Все эти переменные хранятся в массиве SESSIONS. В начале каждого скрипта стоит проверка переменой ok если истина - то хорошо, сли ложь - то авторизация.

Сессии храню в БД, максимальный срок хранения сессии выставлен на 7 дней.

Теперь я не пойму никак, каким образом мне сделать так, чтобы при закрытии браузера и заходе на следующий день у пользователя появлялась его информация из вчерашней сессии?

Вариантов несколько.

1. Как я понял из прочитанного на форуме (советы тем кто спрашивал про запоминание и авторизацию пользователей) и просмотра куков браузера - у этого форума для запоминания пользователя используются куки для хранения id пользователя, хеша пароля и даты последнего визита, по которым формируется информация при моем следующем заходе через запрос к БД по id и хешу пароля. При таком варианте, сессии нет смысла хранить в БД. Но у меня права доступа к разделам именно хранятся в сессиях (как вариант замены - проверять права пользователя при каждом запросе соответствующего раздела отдельным запросом к БД используя его id и пароль - не совсем удобно)

2. Если после успешной авторизации выдавать пользователю куку с SID по которому потом выбирать информацию из таблицы с данными о сессиях? Как минус вижу то, что такую куку может взять кто угодно с компа и стать "авторизованным" с соответствующими правами.

3. После авторизации пользователя привязать SID к его учетной записи, в таблицу с данными о сессиях вносить дату последнего изменения сессии и проверять ее с максимальным временем "жизни". Выдавать куку пользователю с его id и хешем пароля, потом проводить проверку на наличие такого в БД и по SID получать данные сессии. Но чем он тогда принципиально отличается от варианта 2?

Вобщем я в тупике. Одна путаница в голове. Подскажите как мне при хранении сессий в БД после закрытия браузера и повторного посещения страницы выдать пользователю ту информацию, которая была в "его переменных" SESSIONS до закрытия браузера?

 

[HraKK]

Какая разница где хранятся сессии? У вас точно каша в голове.
В куках хранятся id и hash для того чтоб идентифицировать ЕГО сессию которая все равно где храниться, хоть в бочках с селедкой.
А если украдут куку - то звиняйте. А если украдут пароль?

 

[Духовность™]

Сессии храню в БД, максимальный срок хранения сессии выставлен на 7 дней.

Теперь я не пойму никак, каким образом мне сделать так, чтобы при закрытии браузера и заходе на следующий день у пользователя появлялась его информация из вчерашней сессии?

Использовать сессии при авторизации в 90% случаев не нужно. Я бы даже сказал, абсолютно бессмысленно, если вы не собираетесь сохранять какие-то временные данные, когда пользователь ходит по сайту.

Достаточно одних кук - идентификатора пользователя и уникального хэша из данных пользователя, например md(user_password+salt). И при каждом заходе пользователя делать что-то типа

[sql]select * from users where id_user = $_COOKIE[id_user] AND MD5(CONCAT(user_passowrd, salt)) == $_COOKIE[user_hash][/sql]

Подробные алгоритмы на форуме уже обсуждались не раз.

То, что вы сессию храните до 7 суток - не верно. Сессия нужна не для того, что бы её хранить 7 суток! Сессия от слова сеанс:

Промежуток времени, в течение к-рого совершается какое-н. действие, какая-н. работа или часть ее

Т.е. явно, где нужна сессия, это например, многостраничный опрос-тест. Или что-то в этом духе.

Но у меня права доступа к разделам именно хранятся в сессиях

зачем? почему не в БД?

 

[Фанат]

2. Если после успешной авторизации выдавать пользователю куку с SID

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

 

[HraKK]

Достаточно одних кук - идентификатора пользователя и уникального хэша из данных пользователя, например md(user_password+salt). И при каждом заходе пользователя делать что-то типа

йопть.
/me посыпает голову пеплом

 

[Ivanov]

я так понял, что мне необходимо реализовать следующий механизм:

1. Пользователь авторизовался, я в сессии начинаю хранить данные о правах доступа к разделам сайта и выдаю ему куку с его ID и неким хешем

2. Пользователь завершил работу

3. Через некоторое время он опять посещает защищенный раздел сайта и я уже проверяю, если есть установленная ранее кука с его ID и неким хешем, далее если сверка этих данных с данными о пользователях в БД дала положительный результат, то опять формирую НОВЫЕ данные сессии и проверяю есть ли у него права на доступ к этому разделу исходя из его прав. Если же у него нет ранее установленной куки то предлагаю пройти авторизацию

Порядок теперь верен?

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

Или лучше такой вариант: когда данные о последнем визите (время) и максимальное время хранить в куке, а при проверке данных когда посещается страница сверить разницу между "запомнить меня на ... дней" и последним визитом

Наверное разницы большой нет, по скорости будет практически одинаково (в первом случае данные будут получены один раз при авторизации пользователя и сохранены в сессии на перод работы, во втором будут каждый раз браться из куки), а вот с точки зрения безопасности? ведь можно к примеру изменить период "запомнить меня на ... дней" в куке пользователя? но это уже опять из той же оперы

А если украдут куку - то звиняйте. А если украдут пароль?

triumvirat

Но у меня права доступа к разделам именно хранятся в сессиях

зачем? почему не в БД?

сами права хранятся в БД, только они выбираются и запоминаются на время работы в сессии

 

[Духовность™]

йопть.

чего опять не так? ))

 

[Фанат]

при проверке наличия куки и пользователя в системе одновременно проверять не превышен ли лимит с момента последнего визита

У куки есть параметр "время действия".

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

можно.
поэтому если все настолько серьёзно, то пользоваться надо для авторизации не куками и сессиями.

 

[Ivanov]

то пользоваться надо для авторизации не куками и сессиями

а чем?

 

[Фанат]

тебе это не надо.
если бы нужно было, то ты бы уже, заранее знал - чем.

 

[Ivanov]

*****

тебе это не надо.

на перспективу

спасибо всем, кто оказал помощь

 

[Фанат]

читай интернет, умные книжки - и в перспективе узнаешь все что нужно на перспективу.

 

[HraKK]

triumvirat
Да не ничего, все классно. Заваливать мускуль лишним запросом, только потому что тебе лень положить в сессию флаг authorize = true

 

[Фанат]

HraKK, а у тебя мускуль заваливается от лишнего запроса?

 

[HraKK]

Рома
Да нет, почему же. Не в этом дело.
Защиты это не даст никакой, верно? Верно.
Пользы? Таскать в cookies информацию - лишняя нагрузка на трафик. Лишняя нагрузка на мускуль. А главное _зачем_? Если для этого есть хороший инструмент?

Нет конечно, я могу постирать одежду вручную, не обломлюсь. Но если есть стиральная машинка, почему бы не в ней?

К тому же на статических страницах закешированых, хранение признака авторизации в куках вынудит создавать соединение с мускулем только для этого. А это согласись уже весомо.

 

[Фанат]

HraKK
По-моему, вы пишете об одном и том же. Никто данные приложения не предлагает таскать, речь идет только об идентификации пользователя.

А про запрос твое замечание неконструктивное. Во-первых, этот запрос базу не положит. Во-вторых, каждый второй пионэр, интересующийся авторизацией, задает вопрос, как поменять права юзеру на лету. И в-третьих, в реальности при каждом запросе в базу даже ПИШЕТСЯ обычно запись. Так чего уж жалеть чтение?

 

[HraKK]

Не знаю, у меня почему то при посещении страниц нету записи в базу. А в статических - 0 запросов. Но спорить не буду, в любом случае это не HL проект и любая реализация будет приемлема.