Комментарии 87
Т.е. если у какого-то сайта установленно время жизни сессии 5 минут, то и у остальных сайтов сессии будут грохаться каждые 5 минут?
думаю это просто особенность конкретного виртуал-хостинга — время жизни файлов в tmp 30 минут
Ответил в апдейте
Да. если 5 минут поставить - у всего хостинга будут 5 минут.
Это вы молодец, нестандартные проблемы иногда особенно важны
Это какой-то быдлохостинг
На нормальных tmp идет как $HOME/tmp, там и сессии лежат
На нормальных tmp идет как $HOME/tmp, там и сессии лежат
Даже если так, то может встать необходимость иметь, к примеру, два вида сессий - короткие и длинные (запомнить меня). Тогда тоже надо использовать две разные папки для хранения.
"Запомнить меня" в сессии. А может не надо? :)
ну для "запомнить меня" вообще используются куки, security key, и прочие фишки. Делать это на сессиях безсмыслено
Для "запомнить меня" не используются долгоживущие сессии. Сессия должна работать по принципу "живи быстро - умри молодым" :) Куки с идентификатором сессии в идеале должны иметь нулевое время жизни, то есть до закрытия браузера. Сессия она на то и сессия, что в переводе означает "сеанс".
"Запомнить меня" лучше реализовывать так: кидать куку в браузер с каким-то ключом, в базе сохранять хеш этого ключа с привязкой к айдишнику юзера. Когда мы видим, что данный юзер не прошел аутентификацию, но у него есть такой ключ в куках, для которого есть хеш в базе, делаем для него автоматический вход, основываясь на айди. Запись из базы удаляем и кидаем ему новый ключ в куки.
"Запомнить меня" лучше реализовывать так: кидать куку в браузер с каким-то ключом, в базе сохранять хеш этого ключа с привязкой к айдишнику юзера. Когда мы видим, что данный юзер не прошел аутентификацию, но у него есть такой ключ в куках, для которого есть хеш в базе, делаем для него автоматический вход, основываясь на айди. Запись из базы удаляем и кидаем ему новый ключ в куки.
Чем в таком случае отличается запись в базе от файла с сессией - не понятно вовсе.
База или файл тут не важно, это проблема реализации/
Отличие в том, что сессия - это способ сохранять информацию между двумя открытиями страниц. А "запомнить меня" - это автоматическая аутентификация без ввода логина и пароля. Разница в принципе.
Отличие в том, что сессия - это способ сохранять информацию между двумя открытиями страниц. А "запомнить меня" - это автоматическая аутентификация без ввода логина и пароля. Разница в принципе.
Не совсем согласен. Если сессии используются для аутентификации, то как раз "автоматическая аутентификация без ввода логина и пароля" - это и есть "сохранение информации между двумя открытиями страниц". Просто таймаут между этими открытиями несколько больший, чем при использовании сессий для незареганных пользователей.
Нет, это разные вещи, попробуйте понять различие самостоятельно :)
Немного подскажу: в сессии вы храните просто любые данные, которые нельзя терять между двумя открытиями страницы. "Запомнить меня" - это освобождение пользователя от необходимости при следующем посещении сайта вводить логин-пароль, система делает это как бы за него, но происходит процесс аутентификации, входа в систему, со всеми вытекающими.
Немного подскажу: в сессии вы храните просто любые данные, которые нельзя терять между двумя открытиями страницы. "Запомнить меня" - это освобождение пользователя от необходимости при следующем посещении сайта вводить логин-пароль, система делает это как бы за него, но происходит процесс аутентификации, входа в систему, со всеми вытекающими.
Вот как раз я и говорю, что принципиально это одно и то же. Если использовать сессии для авторизации - то именно по сессии система узнаёт пользователя и понимает, что он авторизован.
Это и есть пример того, что вы называете "просто любые данные, которые нельзя терять между двумя открытиями страницы"
Это и есть пример того, что вы называете "просто любые данные, которые нельзя терять между двумя открытиями страницы"
Нет, еще раз повторю: разные вещи.
Можно делать длинные сессии для этого, но это неправильно. Сессия должна жить до закрытия браузера. Кстати, при установке времени жизни куки сессии в 0, в IE (проводил эксперименты, но у же не помню во всех версиях или нет) сессия работает даже при отключенных куках, то есть такие куки IE все же принимает.
Можно делать длинные сессии для этого, но это неправильно. Сессия должна жить до закрытия браузера. Кстати, при установке времени жизни куки сессии в 0, в IE (проводил эксперименты, но у же не помню во всех версиях или нет) сессия работает даже при отключенных куках, то есть такие куки IE все же принимает.
Вы утверждаете, что это неправильно, но не говорите почему именно. Вот мне лично не ясно.
Поясню почему я не вижу ничего в страшного и неправильного в этом - никакого принципиального отличия от вашего предложения: В вашем случае вы хотите хранить соответствие некоего ключа и номера пользователя в базе, а я храню то же самое в файле сессии. При этом я с легкостью могу хранить там неограниченное количество параметров, а вам нужно либо ввобдить поле для сериализованных параметров (считай заново писать phpшные сессии, но уже не на си, а на php =) ), либо для каждого параметра делать отдельное поле.
Если сделать хандлер для хранения сессии в БД - то различий нет вообще.
Хотя есть одно принципиальное отличие - реализация. Вы хотите потратить время на написание кода, который фактически будет выполнять функции уже реализованные на уровне, с позволения сказать, ядра php.
И еще - сессия НЕ обязана жить до закрытия браузера.
И еще - в PEAR::Auth классе используются именно сессии. И они не рвутся по закрытию браузера.
Поясню почему я не вижу ничего в страшного и неправильного в этом - никакого принципиального отличия от вашего предложения: В вашем случае вы хотите хранить соответствие некоего ключа и номера пользователя в базе, а я храню то же самое в файле сессии. При этом я с легкостью могу хранить там неограниченное количество параметров, а вам нужно либо ввобдить поле для сериализованных параметров (считай заново писать phpшные сессии, но уже не на си, а на php =) ), либо для каждого параметра делать отдельное поле.
Если сделать хандлер для хранения сессии в БД - то различий нет вообще.
Хотя есть одно принципиальное отличие - реализация. Вы хотите потратить время на написание кода, который фактически будет выполнять функции уже реализованные на уровне, с позволения сказать, ядра php.
И еще - сессия НЕ обязана жить до закрытия браузера.
И еще - в PEAR::Auth классе используются именно сессии. И они не рвутся по закрытию браузера.
Вы не поняли. Сессии нужно использовать, не надо ничего переписывать, никакие свои хендлеры не нужны. Но. Сессия - это сеанс. Закончился сеанс - запускай новый. Сеанс не должен быть бесконечно долгим, сеанс, это процесс работы с сайтом на короткое время. В этом принцип работы сессии.
Вы же предлагаете использовать длинные сессии для того, чтоб пользователь не вводил заново логин-пароль. А я говорю, что для этого надо сделать систему автоматической аутентификации на основе кука, с заведением новой сессии.
Да, топором тоже можно забить гвоздь, но он для этого не предназначен, а есть молоток.
Если хотите делать длинные сессии - ну что ж, ваше право, переубедить не могу.
Вот, почитайте, на всякий случай:
http://phpfaq.ru/sessions
Вы же предлагаете использовать длинные сессии для того, чтоб пользователь не вводил заново логин-пароль. А я говорю, что для этого надо сделать систему автоматической аутентификации на основе кука, с заведением новой сессии.
Да, топором тоже можно забить гвоздь, но он для этого не предназначен, а есть молоток.
Если хотите делать длинные сессии - ну что ж, ваше право, переубедить не могу.
Вот, почитайте, на всякий случай:
http://phpfaq.ru/sessions
Ну статью по ссылке я читал.
Переубедить действительно не можете, потому что ни одного конкретного факта, почему именно сессия не может быть долгой, за исключением постоянной аппеляции к переводу слова session.
И сессии - это в данном случае не топор, а именно молоток. А ваша "система автоматической аутентификации на основе кука" - это камень.
Зачем брать камень и им наживлять гвоздь, если молотком можно и наживить и забить.
Если вам необходимо отметить факт того, что пользователь давно не был на сайте - можно хранить в ней время последнего посещения. Пришел пользователь - вы увидели, что его не было к примеру 24 часа, отметили этот факт. Ну если вам так хочется создать новую сессию - перегенерите id уже готовой сессии - будет вам "новая", хотя я никак не пойму, зачем вам это нужно, а обьяснять вы не хотите =)
Ну а факт закрытия браузера фиксировать - это паранойя в чистом виде =)
Переубедить действительно не можете, потому что ни одного конкретного факта, почему именно сессия не может быть долгой, за исключением постоянной аппеляции к переводу слова session.
И сессии - это в данном случае не топор, а именно молоток. А ваша "система автоматической аутентификации на основе кука" - это камень.
Зачем брать камень и им наживлять гвоздь, если молотком можно и наживить и забить.
Если вам необходимо отметить факт того, что пользователь давно не был на сайте - можно хранить в ней время последнего посещения. Пришел пользователь - вы увидели, что его не было к примеру 24 часа, отметили этот факт. Ну если вам так хочется создать новую сессию - перегенерите id уже готовой сессии - будет вам "новая", хотя я никак не пойму, зачем вам это нужно, а обьяснять вы не хотите =)
Ну а факт закрытия браузера фиксировать - это паранойя в чистом виде =)
Блин, писал-писал и не запостилось...
В двух словах. Сессия изначально предназначена для кратковременного хранения данных, чтоб они не пропали при переходе от страницы к странице. Лишнее, устаревшее чистится. В этом предназначение сессии. Представьте, что у вас миллионы юзеров, и в каждой сессии по несколько десятков килобайт данных, и все это хранится в memcache. Спрашивается, зачем хранить все для всех, когда онлайн только 5-6% юзеров, скажем?
Но опять же - ваше право поступать как вам вздумается. Уверен, что на многих серьезных проектах сделано по моей схеме. :)
В двух словах. Сессия изначально предназначена для кратковременного хранения данных, чтоб они не пропали при переходе от страницы к странице. Лишнее, устаревшее чистится. В этом предназначение сессии. Представьте, что у вас миллионы юзеров, и в каждой сессии по несколько десятков килобайт данных, и все это хранится в memcache. Спрашивается, зачем хранить все для всех, когда онлайн только 5-6% юзеров, скажем?
Но опять же - ваше право поступать как вам вздумается. Уверен, что на многих серьезных проектах сделано по моей схеме. :)
Ну вот я и говорю - хранения сессий в БД, как уже было сказано - практика, проверенная на ХайЛоад проектах, но это лишь проблема сториджа, а не принципа. Если все данные хранятся в БД, то никаких проблем с вашим примером не наблюдается =)
При высоких нагрузках сессии лучше хранить в памяти. В вашей схеме память будет безбожно забиваться без толку. А если придется перезагрузить зависнувший сервер, скажем - у всех пропадет "запомнить меня". А все почему? Потому что долгосрочное запоминание пользователей - не дело сессий ;)
не согласен с первой фразой. При высоких нагрузках делается балансировка между несколькими серверами. А хранение сессий в памяти делает невозможной такую балансировку.
Собсно неверность первой фразы позволяет не рассматривать дальнейшие =)
Собсно неверность первой фразы позволяет не рассматривать дальнейшие =)
Так же, как для БД выделяется отдельный сервер, так и для memcache выделяют отдельный сервер.
Но если БД рестартнуть - сессии останутся =)
А вот если рестартануть memcache, то пропадут. Из этого делаем вывод, что для сессий нельзя использовать memcache?
почему же, можно, но если хранить сессии в мемкеш, то нужно обеспечить их сохранность. Как это делать - это уже другой разговор - дампами или еще репликацией - это не суть. Суть нашего спора не в мемкеше, а в сессиях =)
Фактически же вы предлагаете метод "как бы сохранения" сессиий, а точнее их кусочка в БД. То есть по сути из мемкеша вы обеспечиваете частичную копию сессии =)
Да, но два скрипта юзают одну и туже папку, и устанавливают разное время жизни сессий, соответственно, скрипт где меньше время жизни будет с "жадностью" удалять все без исключения сессии не разбирая он их ставил, или нет.
Это то, как я понял сию статью.
Мораль. Хочешь юзать разное время жизни - используй разные папки для хранений сессий.
Это то, как я понял сию статью.
Мораль. Хочешь юзать разное время жизни - используй разные папки для хранений сессий.
+1
C ноября 2007...
...Обычно меясйц, но если есть хвосты, то полугода может длиться.
Ну так надо сначала мануал читать, а потом программировать.
ахахаха =)
Что называется "всех не перестреляешь".
Нельзя объять необъятное.
Что называется "всех не перестреляешь".
Нельзя объять необъятное.
Спасибо, поржал. Вы веб-разработчик? Весь мануал по Апачу прочитали? Все статьи из man по FreeBSD или где у вас сервер? О том, цитируете ли вы спецификацию PHP наизусть, можно даже не спрашивать?
Стараюсь читать мануал ко всем функциям PHP, которые приходится использовать.
Если уж используешь сессии, то будь любезен прочитать сначала, что пишут сами разработчики, чтоб знать тонкости и подводные камни.
Так можно по каждой фигне, которую не удосужился прочитать в мане, устраивать гуглинг, а потом постить это на Хабр, как великое открытие.
Если уж используешь сессии, то будь любезен прочитать сначала, что пишут сами разработчики, чтоб знать тонкости и подводные камни.
Так можно по каждой фигне, которую не удосужился прочитать в мане, устраивать гуглинг, а потом постить это на Хабр, как великое открытие.
Я не говорил, что это великое открытие. Просто полезная информация по проблеме, с которой я столкнулся и в сети ответа не нашел.
А мануал по сессиям я прочел, но вот там есть такая хитрая страничка с перечислением директив php.ini, и именно в ней указан этот аспект. Более нигде об этом не сказано. Не удивительно, что я, как и многие, это упустил из вида.
А мануал по сессиям я прочел, но вот там есть такая хитрая страничка с перечислением директив php.ini, и именно в ней указан этот аспект. Более нигде об этом не сказано. Не удивительно, что я, как и многие, это упустил из вида.
Понятно, читайте внимательнее в следующий раз.
Ой, о чем это я, не читайте, конечно, а то тут, я смотрю за рекомендации читать ман перед работой карму в минус загоняют :))
Ой, о чем это я, не читайте, конечно, а то тут, я смотрю за рекомендации читать ман перед работой карму в минус загоняют :))
=))))
Рекомендации и укор - это разные вещи.
п.с. я никому пока карму не трогал =)
Рекомендации и укор - это разные вещи.
п.с. я никому пока карму не трогал =)
Карма на хабре и веб-разработка разные вещи. Вам не в этот топик
Спасибо, вы такой умный, все разъяснили.
Я не дрочу на карму, пусть хоть минус бесконечность будет, мне от этого ни тепло, ни холодно, просто ситуация посмешила.
Я не дрочу на карму, пусть хоть минус бесконечность будет, мне от этого ни тепло, ни холодно, просто ситуация посмешила.
Да успокойтесь вы. я не со зла. просто уже на самом деле задолбали постоянно все говорить о карме. кругом карма, карма. хрен с ней. тут есть информация. к тому же ценная, и нахрен карму. з.ы. насчет мануалов согласен, но не настолько радикально, все знать невозможно
Общество здесь — это всего лишь модель Большого Настоящего Мира. И здесь точно так же как и Там не любят тех кто безаппеляционным тоном указывает как надо жить другим. Не желая узнать перед этим как эти другие живут и каковы обстоятельства «инцидента».
Ой, ошибся веткой.
Ой, ошибся веткой.
Сначала надо пиво пить, а потом программировать =)
Папку надо сменить не для того, чтобы использовать время жизни. Папку нужно сменить, потому что это дыра: у кого-то постороннего есть доступ к вашим данным. Их можно анализировать, фальсифицировать, что угодно. И раз уж хостер про это не знает, параллельно стоит задуматься, о чем ещё интересном не в курсе тамошние сисадмины.
Храните сесси в Бд используя session_set_save_handler(), это даже надежней чем хранить их в memcache используя ini_set('session.save_handler', 'memcache');
"одобрено хай лоад проектами" (с)
"одобрено хай лоад проектами" (с)
Хорошая идея. Я давно хочу это реализовать, но руки не доходят =)
Наверное время пришло, если болше идей не будет ;)
Ну зачем сидеть и лепить велосипед? http://phpclasses.org вам в помощь чтобы потом на таких мелочах по полдня не тратить.
А если и это не помогает и вы пользуетесь Огнелисом, то обратите внимание на about:config - browser.sessionstore.interval
Почитайте про Garbage_Collection... Там все есть...
Например, тут: http://habrahabr.ru/blog/think_aloud/231…
Например, тут: http://habrahabr.ru/blog/think_aloud/231…
Что же вы стесняетесь? огласите название хостинга, чтобы все знали!
Зачем скрывать, чтобы кто-то ещё попал? Думаю, что это не так.
Зачем скрывать, чтобы кто-то ещё попал? Думаю, что это не так.
мда. Оптимизировал я как-то такие сайты. Суть был в том, что сессии хранились в собственных папках, а чистилась только одна /tmp. В итоге, время открытия страницы составляло примерно 100мс на неслабеньком проце, сервак просто дымился (при 200 тысячах файлов-то для каждого из 3 хостов, которые там по 2 года лежали).
После чистки сессий сайты стали открываться по 10мс максимум.
В общем, добавьте еще один Update про чистку сессий
После чистки сессий сайты стали открываться по 10мс максимум.
В общем, добавьте еще один Update про чистку сессий
Не очень понял, что надо добавить +)
что при установке для хранения сессий не директории по умолчанию, ее тоже нужно по крону чистить с заданной частотой, иначе у вас сервер со временем ляжет из-за кастомных директорий
Странно. Все нормально чистится самим php.
нет. все нормально должно чиститься.
если в кроне не стоит, и то и чиститься не будет. Я именно про такие случаи. А в крон после назначения кастомной папки обычно забывают добавить
хотя, может зависет от настроек PHP: будет ли он проверять, есть ли в папке старые сессии, чтобы их удалить. В таком случае это всегда будет тормозить при большом (от нескольких тысяч сессий) количестве файлов: ведь нам нужно при создании нового файла найти все файлы, которые старше его больше, чем на допустимое время.
я сначало подумал про экзамены, потом подумал что надо заранее сдать зачеты, потом начал читать дальше.. =D
Здорово хранить сессии нескольких приложений в одной папке, особенно если сервер виртуальный и к /tmp имеют доступ все, кому не лень
Можно в придачу добавить собственный обработчик ошибок
Есть еще одна причина пропадания сессий. Сами недавно столкнулись, долго не могли понять, в чем дело. Решение нашлось здесь: http://valera.ws/2008.01.09~cookies/
Вкратце. Если на странице есть счетчик, устанавливающий куки таким образом: document.cookie=”c=1”;, то в браузере создается отдельная запись для каждого каталога сайта (а с mod_rewrite их может быть сколько угодно). Через некоторое время пул записей в браузере переполняется и первые куки начинают удаляться, грохая соответственно сессию. Выглядит это как разлогинивание юзера в совершенно произвольный момент времени. Исправляется так: document.cookie=”c=1;path=/”;
Вкратце. Если на странице есть счетчик, устанавливающий куки таким образом: document.cookie=”c=1”;, то в браузере создается отдельная запись для каждого каталога сайта (а с mod_rewrite их может быть сколько угодно). Через некоторое время пул записей в браузере переполняется и первые куки начинают удаляться, грохая соответственно сессию. Выглядит это как разлогинивание юзера в совершенно произвольный момент времени. Исправляется так: document.cookie=”c=1;path=/”;
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Время жизни сессии