Как быть со старыми файлами сесий
- Автор темы Кощей
- Дата начала
Корзину в магазине (для оптовых продавцов) юзеры наполняют в течении 2-3х дней, прежде, чем сделать заказ, и им это важно
> они у пользователя живут не дольше, чем пользователь держит открытым браузер
> тачки держит всегда включенными
Какую-то ахинею пишешь. Конечно все всё выключают. Поэтому сессии хранит сервер, а не запущенный браузер. Время жизни куки - вечно. Но юзерам важно сохрнять в течении пары дней одно и тоже состояние на сайте. Чтобы не писать каких-то велосипедов, просто по умному чистим сессии.
> они у пользователя живут не дольше, чем пользователь держит открытым браузер
> тачки держит всегда включенными
Какую-то ахинею пишешь. Конечно все всё выключают. Поэтому сессии хранит сервер, а не запущенный браузер. Время жизни куки - вечно. Но юзерам важно сохрнять в течении пары дней одно и тоже состояние на сайте. Чтобы не писать каких-то велосипедов, просто по умному чистим сессии.
сидеть на сайте с настройками куки=0 и временем жизни по-дефолту - вот это реальный велосипед
дело в том, что IE имеет глюк - при открытии нового окна (по Window.open) и закрытии оного может уничтожится нулевая кука, не смотря на оставшее родительского окно (лечится долгой кукой или циклом на яве, которая тупо каждую секунду ставит доп. куку с номером сессии)
звонок и зеркальце заднего вида не забудь приделать =)
и ваще, руки надо откручивать тем, кто херит сессии юзеров по дефолтному времени (либо не имеет иной системы восстановления данных - но ее нужно программить)
дело в том, что IE имеет глюк - при открытии нового окна (по Window.open) и закрытии оного может уничтожится нулевая кука, не смотря на оставшее родительского окно (лечится долгой кукой или циклом на яве, которая тупо каждую секунду ставит доп. куку с номером сессии)
звонок и зеркальце заднего вида не забудь приделать =)
и ваще, руки надо откручивать тем, кто херит сессии юзеров по дефолтному времени (либо не имеет иной системы восстановления данных - но ее нужно программить)
dimagolov
Новичок
ИМХО хранить карзины лучше не в сессиях а в базе по множеству причин... а сессии надо использовать именно как сессии.
-~{}~ 12.07.09 13:32:
кстати, если бы сессия использовалась по назначению, то и проблемы с потерей сессионной куки не возникало. даже если бы такое и происходило, то происходил бы автологин по соответствующей куке и все что нужно подтягивалось бы из базы. для юзера это бы вообще было бы незаметно.
-~{}~ 12.07.09 13:32:
кстати, если бы сессия использовалась по назначению, то и проблемы с потерей сессионной куки не возникало. даже если бы такое и происходило, то происходил бы автологин по соответствующей куке и все что нужно подтягивалось бы из базы. для юзера это бы вообще было бы незаметно.
Ты читаешь, что тебе пишут? Чтобы залить данные в базу - нужно что-то писать. Ради чиха - это накладно. И от этого изменится логика сайта - у юзера будут единые данные, а не разные (по компам).
> то и проблемы с потерей сессионной куки не возникало. даже если бы такое и происходило, то происходил бы автологин по соответствующей куке и все что нужно подтягивалось бы из базы. для юзера это бы вообще было бы незаметно.
это - бред!.. Браузер при некоторой причине херит куку. По какому основанию ты его повторно авторизуешь при первом же запросе после потери? В куках - пусто. В реферере - пусто. Из воздуха достанешь? С ненулевой кукой такого нет. С ява-восстановленим - тем более.
> то и проблемы с потерей сессионной куки не возникало. даже если бы такое и происходило, то происходил бы автологин по соответствующей куке и все что нужно подтягивалось бы из базы. для юзера это бы вообще было бы незаметно.
это - бред!.. Браузер при некоторой причине херит куку. По какому основанию ты его повторно авторизуешь при первом же запросе после потери? В куках - пусто. В реферере - пусто. Из воздуха достанешь? С ненулевой кукой такого нет. С ява-восстановленим - тем более.
dimagolov
Новичок
на основе куки, у которой срок жизни не 0 а 2 недели и которая обеспечивает автологин. если пользователь того захотел и поставил соответствующую галку при входе на сайт. в твоем же варианте ты его фактически заставляешь делать автологин своей вечно живущей кукой, причем абсолютно непрозрачно для пользователя. простейший пример, когда это выйдет боком, это чужой комп (интернет кафе и пр.)
не понимаю такой лоники. когда 10 человек работают под одним и тем же логином может для кого-то и нормальная практика, но для меня нет. да и для меня логично, что зайдя на сайт с коммуникатора я найду те же данные, что я сохранил на нем из офиса сегодня, а не те, что сохранил на коммуникаторе неделю назад.
а то сессия у тебя не на диске хранится. но зато у тебя возникла проблема когда браузер херит сессионную куку, из-за этого пришлось менять дефолтный механизм работы сессий и писать кастомный garbage-collector для файлов сессий. это мне кажется слишком дорогой расплатой за "простоту" сохранения данных в сессии. тем более, что сессия это никак не место хранения данных.
кстати, если это магазин, то его хозяевам могло бы быть интересно отслеживать что оптовики готовятся заказать, смотреть соотношение наполнения корзин к реальным заказам и т.п. статистику о том, как клиенты делают выбор покупки. держи корзинки в базе это делалось бы тривиально, а держа их в сессиях ты лишаешь себя возможности как-то анализировать корзины.
Rin
*
Поддерживаю (я так и делаю):
* по умному чистить долгоиграющие сессии
* хранить корзины в базе
dimagolov
>пример, когда это выйдет боком, это чужой комп (интернет кафе и пр.)
боком не выйдет, если предусмотреть ссылку для выхода из авторизации -- сессия не разрывается, но ставится флаг, что пользователь не авторизован. В постоянной сессии можно хранить некоторые данные для частичного автозаполения форм, например, логин или ФИО, а так же другую служебную информацию, например, для антиспама и антифлуда.
В своих проектах я session_id использую не стандартный, а строю сам на основе SERVER_NAME, HTTP_USER_AGENT (обрезаный), HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE; а для роботов ещё и REMOTE_ADDR, хотя возможно, это уже лишнее (параметры из GET для проиндексированных страниц поисковики вырезать умеют).
* по умному чистить долгоиграющие сессии
* хранить корзины в базе
dimagolov
>пример, когда это выйдет боком, это чужой комп (интернет кафе и пр.)
боком не выйдет, если предусмотреть ссылку для выхода из авторизации -- сессия не разрывается, но ставится флаг, что пользователь не авторизован. В постоянной сессии можно хранить некоторые данные для частичного автозаполения форм, например, логин или ФИО, а так же другую служебную информацию, например, для антиспама и антифлуда.
В своих проектах я session_id использую не стандартный, а строю сам на основе SERVER_NAME, HTTP_USER_AGENT (обрезаный), HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE; а для роботов ещё и REMOTE_ADDR, хотя возможно, это уже лишнее (параметры из GET для проиндексированных страниц поисковики вырезать умеют).
dimagolov
Новичок
Rin, а зачем такая соль? Если бы ты хранил это в сессии для предотвращения ее кражи, то я бы понял это, правда непонятно что вору, который украл SID, помешает украсть и все остальное, что шлет клиент на сервер. Выходит, что ради повышения безопасности SID-а это не годится. А формировать сам session_id (случайный) используя параметры клиента как соль тем более выглядит бесполезной активностью...
Rin
*
Да, можно было хранить соль внутри сессии, но я сделал по-другому.
Для примера: cugbsk7t6i-2ufbk36
В первой части uniqid(), во второй -- контрольная сумма, которая вычисляется на основе первой + SERVER_NAME, HTTP_*, REMOTE_ADDR и некоторого секретного ключа.
В случае воровства SID не пройдет проверку по контрольной сумме и будет создан новый SID.
Так же из этого SID можно вытащить дату и время создания сессии, даже если сам файл сессии уже удалён с сервера.
Для сбора статистики очень удобно. У меня при неактивности посетителя файл сессии удаляется через неделю.
Для примера: cugbsk7t6i-2ufbk36
В первой части uniqid(), во второй -- контрольная сумма, которая вычисляется на основе первой + SERVER_NAME, HTTP_*, REMOTE_ADDR и некоторого секретного ключа.
В случае воровства SID не пройдет проверку по контрольной сумме и будет создан новый SID.
Так же из этого SID можно вытащить дату и время создания сессии, даже если сам файл сессии уже удалён с сервера.
Для сбора статистики очень удобно. У меня при неактивности посетителя файл сессии удаляется через неделю.
dimagolov
Новичок
с учетом наличия REMOTE_ADDR проверка не пройдется и при динамической смене IP клиента провайдером и при переключении мобильного клиента с одного провайдера на другого. А если отбросить REMOTE_ADDR, то не останется ничего, чего вор не может перехватить вместе с SID. то есть надо понимать, что от подобного практической пользы (кроме того, что ты можешь вытащить дату-время создания), особенно в плане безопасности нету, аналогичный эффект был бы от хранения REMOTE_ADDR в самой сессии.
Слушайте. Зачем? Никто обычно не угоняют сессии (ни одного не знаю), извините, но если захотят сломать, то не будут извращаться над сессиями, а тупо спи..т пароли залив трояна по ссылке с сайта.
Люди на платежных системах (в основном не Русских) используют даже "введите код" селектами, пароль - нажатием виртуальных кнопок на сайте, озвучите капчу и постучите в буден, что бы сделать платеж, наивно думая что вот оно - самое безопасное, а вот, хрен вам. Троян умный - он берет и делает скриншоты, и отсылает их....
Так что - бредовая безопасность
(у меня кстати. мобильный CDMA интернет, дк. мой провайдер, бвк, заблокировал трассировку, говорят, мол, небезопасно. У вас, rin, таже самая проблема)
Люди на платежных системах (в основном не Русских) используют даже "введите код" селектами, пароль - нажатием виртуальных кнопок на сайте, озвучите капчу и постучите в буден, что бы сделать платеж, наивно думая что вот оно - самое безопасное, а вот, хрен вам. Троян умный - он берет и делает скриншоты, и отсылает их....
Так что - бредовая безопасность
(у меня кстати. мобильный CDMA интернет, дк. мой провайдер, бвк, заблокировал трассировку, говорят, мол, небезопасно. У вас, rin, таже самая проблема)