Как правильнее реализовать "запомнить меня"

[shornikov]

Как правильнее реализовать "запомнить меня"

Добрый день.

Хочется сделать "запомнить меня", чтобы пользователь не в водил пароль при каждом открытии сайта. И более того, все настройки хранившиеся в сессии - были востановлены.

Логичный, как мне кажется, способ - переносим сессии в базу данных с помощью session_set_save_handler.
создаем таблицу InnoDB из sid, userdata, timestamp.
Сессии работают и хранятся.
Это практика.

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

Пробема.
Последовательное выполнение кода из серии (код не боевой*):

$_SESSION['user']="bla-bla";
mysql_query("update session set remember='Уникальное значение' where siв=".session_id());

не приводит к обновлению записи. Ошибок не выдает.
Есть мнение что запись в момент обновления блокирована.
Пробовал перед записью поля remember закрывать сессию c помощью session_write_close(), тогда запись проходит, но последующий session_start() ругается на невозможнось инициализировать хранилище*.

Возможно, надо хранить remember и копию сессионых данных в отдельной таблице - но это приводит к лишним телодвижениям. при каждом обновлении сесии надо дополнительно вызывать синхронизацию, что не интересно.

Теперь вопросы:
а) можно ли побороть блокировку записи, если дело в ней.
б) я вообще верной дорогой иду?


* К сожалению, рабочий код дома, а я на работе. Если кто-нибудь захочет посмотреть код, выложу вечером. Голова забита данной проблемой, терпеть до вечера сил нет. Извините.

 

[HraKK]

COOKIE

 

[shornikov]

Хранить в куках логины и шифрованные пароли - можно, но если там хранить и другую инфолрмацию, хранящуюся в сессии - это может оказаться накладно.

Мне интересно, как сделать полное восстановление сессии по куке, при том что время хранения сессии не увеличено искуственно.

 

[Beavis]

shornikov
в куке надо хранить только хеш уникальной для каждого пользователя информации, по которому уже загружать в начале сессии данные о пользователе

 

[shornikov]

я это понимаю.
Было бы удобно для восстановления использовать туже таблицу, где хранятся сессии (см. выше) у меня не выходит писать туда вместе с "ядром php".
А если хранить данные сессии и ассоциированный с ними хеш куки в другой таблице - возникает вопрос, как изящно синхронизировать данные сессии и данные, хранящиеся в этой таблице. Понятно, что можно на каждое $_SESSION[]=
дописывать еще update... но это как-то топорно.
можно переписать session_set_save_handler(write), чтобы данные писались в два места, но php наверно опять залочит запись.

 

[Gas]

shornikov
ты неправильно понимаешь значение сессий, а так-же persistent настроек пользователя.
"Запомнить меня" не подразумевает использование одной и той-же сессии для пользователя. Beavis сказал тебе уже что в cookie хранится уникальный ключ, идентифицирующий пользователя. Если пользователь не залогинен и есть этот ключ, то ищется в базе пользователь, автоматом логинится, сессия может быть совершенно другая. После такого логина в сессии должно быть тоже самое что и после ввода логина/пароля. Если есть какие-то настройки пользователя, то хранить их нужно в базе/файле, то есть в persistent storage и после логина можно (но не обязательно) засовывать в сессию, чтоб каждый раз не дёргать из базы.

 

[shornikov]

Gas, я вас понял.
Видимо все так и делают и мне придется.

Но на мой взгляд, ведь кроме проблем реализации (возможно только моих),
Ведь мы получаем автоматическое хранилище, запись в которое реализована на уровне ядра, тот-же самый Id позволяет идентифицировать пользователя, что уменьшает количество кук, доступ к значениям проще, количество запросов к базе уменьшается.
Минусы - таблица больше, другой комп с тем-же пользователем - несколько лишнего кода

Я что-то не учитываю?

Раз восстанавливать значения сессионных переменных прийдется из другого хранилища, возникает вопрос - как держать там актуальные данные?

В конце каждого скрипта дергающего сессии делать update хранилище set userdata=$_SESSION?
или есть способ красивее?

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

 

[Gas]

Gas, я вас понял.

при общении на форумах, предпочитаю на ты.

мест хранения данных меньше

почему меньше, не знаю что у тебя за настройки/параметры пользователей, например, настройки "язык интерфейса", "отправлять уведомления на e-mail" должны храниться в базе или в каком-то постоянном хранилище. Я должен зайти с другого компьютера, почистить куки, но эти настройки должны подхватиться. В сессию их записать можно в момент логина(неважно, ввёл я логин/пароль или сработал механизм "запомнить на сайте"), своего рода кеш. При изменении этих настроек - update в базе и обновление в сессии.

Сесии не для того используеются, часто наоборот в сессию садится IP+UserAgent и если не совпадают, то стартует новая сессия, безопасность типа. А ты предлагаешь наоборот - вечные сессии, они не для этого.
http://phpfaq.ru/sessions#use

 

[shornikov]

Gas, меньше (только в контексте "запомнить меня") потому-что, одна кука c идентификатором сессии, а не две - идентификатор и для отдельная для запомнить (где я успел посмотреть, именно так), все хранится в одном месте (где сессии), а не в двух (сессии и инфа для восстановления).

Настройки конечно надо хранить и в "нормальной" базе, но
в моем предложении выбрасывается процедура
select setting from user where user=$_SESSION['user'], если человек на том-же рабочем месте (это обычно). Для тогоже пользователя с другого компа поднимаем туже сессию основываясь на данных сессии.

Да - с безопастностью более запущено, но, есть масса проектов, где идентификация пользователя нужна для удобств самого пользователя, а не для его ограничения. Можно в таких случаях использовать куки, но они засоряют траффик.

Если есть желание - можно и дальше обсудить.

Я видимо потыркаюсь с lock'ом записи, если не выйдет, сделаю как все.

Так все делают?
* если стоит галочка делаем куку SAVE;
* при каждом изменении данных сессии (вот эта суета мне не симпатична) и наличии куки SAVE сохраняем в данные в таблицу "ЗНАЧЕНИЕ SAVE" "ДАННЫЕ СЕССИИ".
*если у пользователя есть кука SAVE но нет сессии - заводим ему сессию, кладем туда из таблицы "ДАННЫЕ СЕССИИ", (рефреш страницы - логин подхватывается)

 

[Фанат]

надо просто разделять понятие сессий и настроек пользователя.
и понимать, что это как бы совсем разные вещи. сессия временна, а настройки постоянны.
если это понять, то все проблемы как рукой снимет

 

[shornikov]

*****, добрый день.
Есть НАСТРОЙКИ, а есть "когда я был на этой странице, я отсортировал таблицу по второму столбцу".
Надеюсь, согласитесь, хранить такое в базе настроек излишне.
пользователю в общем случае пофиг, как оно было отсортировано, но будет приятно.
Если программер это может сделать путем $session['sorttable1']=2;
наверное он это сделает.
А если ему понадобится, проверить права пользователя, залочить строку, считать поле с настройками, затем разбить их на значения, перезаписать sorttable1, сохранить в базу, разлочить строку - то он скорее всего забьет на этот процесс.

Я когда начинал - подразумевал именно такие настройки, которые в общем, не жалко. Хорошо если они сохранятся, но насиловать базу не имеет смысла. Потом увлекся, да...

 

[Фанат]

"когда я был на этой странице, я отсортировал таблицу по второму столбцу", то это уже другая страница.
придумай другой пример

 

[shornikov]

почему это?
данные то те-же самые.
если ты намекаешь на ?sort_by_row=2, так это не обязательно. сортировка могла быть произведена через JS, а сортировочный столбец отправлен на сервер ajax'ом.

или что ты имеешь в виду?

 

[Фанат]

это обязательно

-~{}~ 16.04.10 15:17:

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

 

[shornikov]

Я не за решением пришел, хотя для стандартного подхода готового решения я на сайте не нашел.
И не потроллить.
Хотел узнать, почему не выходит - на это никто не ответил, хотя перечитал faq по сессиям. База не файл, но видимо тоже лочится.
Почему так нельзя - тоже обошлось общими фразами - "не принято так".

Раз уж ты вспомнил анекдот, то я упомяну. На каком-то сайте сказали что если бы все вещи использовались по назначению, то анального секса бы не существовало (извините).

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

А по-поводу "другой страницы" все равно я не понял,что ты имел в виду.

Удачных выходных всем

 

[С.]

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

 

[shornikov]

В каком месте ты отделяешь настроечные данные от сессионных?

В своей голове. Поскольку мы сейчас говорим не о конкретном проекте, а о некоторой абстракции, то я бы
пытался сохранить в продляемой сессии такие данные, которые бы
с точки зрения пользователя мне было комфортно, если бы они сохранялись, а с точки зрения программиста кодирование их сохранения их было бы задачей с минимальным приоритетом, из серии "пользователь переживет и так".

 

[dimagolov]

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

 

[shornikov]

Dimagolov, раз уж ты написал такой большой абзац, может и список причин приведешь? Или линк хотя-бы.
Хотелось бы все-таки знать, почему нельзя. для расширения кругозора и осознания своих ошибок.

 

[dimagolov]

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

1. безопасность
2. сборка мусора
3. привязка к конкретному браузеру
4. блокировка сессии при записи, в первую очередь когда хранилище в файлах, и вообще вопросы конкуренции если нет блокировок