Сессии – что лучше?

[Gunger]

Просьба аргументировать свой выбор, плюсы-минусы.

[ega]

Выбрал первый вариант, потому что не пишу на php, но хотел посмотреть результаты.

[nayjest]

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

[ashofthedream]

использование session_set_save_handler(). Хотя вот нередко видел изобретенный велосипед, который держался на обычном функционале сессий...

[Gunger]

В том же Друпале используется именно собственный обработчик, основанный на общем функционале + session_set_save_handler().

[Tigger]

Да, и правда, что может быть лучше сессий... Только защита диплома и диссертаций, наверное.

[abrwalk]

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

[fogx]

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

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

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

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

[Gunger]

Присылай в личку, опубликую с твоими копирайтами, разумеется.
Я сейчас как раз на этой теме заморочен – что лучше. И толковых аргументов нагуглить не могу, к сожалению.

[pinc]

Ты уже можешь - зайди в свой хабрацентр и создай топик - просто не помещай его в групповой блог.

[Davert]

Карму повысил. Ждем статью :)

[nfx]

поднял тебе карму. есть мисль - так почему ее дежрать при себе, если поделиться хочеш...

[diamant]

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

[Gunger]

Вообще я его друг из первого круга и тоже не вижу статьи, к сожалению..

[diamant]

подождём ответа фогса и появления статьи в публичном доступе и тогда поставим плюс :)

[Africa]

свой блог заведи, нефиг зависеть от какой-то кармы

[gro]

На сложных проектах — свой велосипед.
Когда время общей разработки измеряется месяцами, можно потратить полдня на написание и отладку велосипеда и избежать дальнейшего геморроя.
Как PHP всё делает фиг поймешь. Всё складывается в /tmp/, а насколько это безопасно зависит от квалификации админа сервера. Куки пихает со страшным именем, в зависимости от настроек еще может сначала сунуть SID в URL, а может и не сунуть, когда мусор вычистит неизвестно. И так далее и тому подобное.
Кроме того, я храню сессии в базе и могу привязывать к ним другие данные вроде статистики и логов. Со стандартным механизмом так не сделаешь.

[Gunger]

Вот у меня такие же аргументы в пользу собственного велосипедного обработчика, но, глянув на Хабру и Автокадабру я заметил странную разницу — на Хабре, судя по всему, используется собственный обработчик, а на Автокадабре — стандартный. Интересно, чем это вызвано, как мыслят разработчики в конкретных ситуациях.

Кстати, сейчас выяснил подробнее про настройки сессий — почти все минусы решаются либо напрямую установкой директив в php.ini, либо с помощью ini_set().

[glib]

Попробую не согласиться... Это только моё мнение, поэтому как уже оцените - ваша воля. Каждый раз, когда я раньше думал "мая лесапета будет круче" - садился и писал. Было большое чувство удовлетворённости по окончанию писюльки. Со временем обленился вкрай... И начала посещать мысль - "а нет ли готовых решений?". Ведь не даром разработчики во всём мире используют готовые библиотеки и компоненты. Например посмотрите на обилие контролов для ASP.Net и на их цены. цены кусаются а библиотек - валом....
Но что-то я отклонился. Так вот: вы только подумайте - "сколько у ПХП разработчиков (в частности компания Зенд) уже опыта в создании этого движка?" Неужели они за столь длительное время не закрыли дыры в таком частоиспользуемом элементе как Сессии? И неужели они не повышают его быстродействие?
Повторюсь, только моё мнение, что базовой функциональности сессий - с головой хватает для простых сайтов. А для сложных можно использовать как Мемкэш или БД, как уже упоминалось. Но ведь это тоже некоторым образом ограничевает разработчика в определённой области. Например, будете использовать только БД или только файлы и тд.
А почему бы не выбрать что-то среднее? Например создать "обёртку" для стандартной сессии? Написание обёртки и её отладка займёт всего пару часов. Может даже и час :) Но зато эта обёртка будет оценивать ключ для сохранение в сессию и, в зависимости от логики, "нужные" элементы пихать в базу, а не нужные хранить например в памяти... Даже не добираясь до файла. Ведь не все используют на прямую функции работы с МуСКуЛом? :)
А используя класс-обёртку как для доступа к бызе так и для сессии, а также и для других утилит - проект становится более объектно-ориентированным, а также гибким и легко-расширяемым.
session_set_save_handler - хорош, но это немного скрывает ООП, которое и так тяжело проявить в ПХП.
Спасибо, что дочитали эти мысли до данной строки)

[Gunger]

Согласен, что session_set_save_handler() немного не Объектно-Ориентирован (имеется ввиду, что было бы прекрасно отправлять туда готовый объект класса), но с классами есть возможность его использования.

$session = new Session();
session_set_save_handler(array($session, 'open'),
                                                 array($session, 'close'),
                                                 array($session, 'read'),
                                                 array($session, 'write'),
                                                 array($session, 'destroy'),
                                                 array($session, 'gc'));

[glib]

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

[bat]

Да... самое то было бы унаследовать интерфейс.

[gro]

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

[glib]

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

[gro]

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

[glib]

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

[gro]

Остапа понесло...

[dinamyte]

Лёд по этому поводу тронулся уже давно: некоторые косо смотрят на тех, кто что-либо начинает писать сам, уповая на то, что такие люди «изобретают велосипед». А чтобы задаться вопросом: где выбрать существующее решение, а где написать своё — времени не хватает.

[Apostol]

Да нормально в PHP реализованы сессии. Куда складывать, какое давать имя сессии, передавать ли в GET, как часто чистить мусор и тд. — всё настраивается. Для простых проектов — то, что надо. Но когда нужно хранить данные в базе, производить какие-то дополнительные проверки или ещё чего, то легко делается надстройка (session_set_save_handler) и ваши скрипты даже изменять не придётся. ;)

[gro]

Да, можно всё настроить (если доступ к php.ini есть), можно сделать надстроку.
Но если всё равно приходится делать настроки, надстройки, навороты и т.п, то зачем оно вообще нужно? Столько же сил потратим, тёмные места всё равно останутся.

[d1m]

Как было замечено чуть ранее - для 90% задач хватает сессий более чем.

[gro]

Я против сессий ничего и не имею :) И против стандартного механизма так же. Против того, что для 90% задач его хватает, я ничего не говорил. Но, например мне, на 100% задач хватает своего механизма.

[evgwest]

На проектах с большой нагрузкой ИМХО лучшие связки:
save.handler = memcache, либо, для снижения риска потери данных сессии - самописный save.handler в БД + данные сессии кладутся в memcache

[Gunger]

Вариант, использующийся в UMI.CMS.
Вопрос к Вам – save.handler в виде отдельных функций или единым классом?

[evgwest]

а какая разница??? если у вас процедурный подход... тогда функции, если ООП - соответственно, объекты

[Gunger]

Разница есть. Я явно чувствую, что объектный вариант будет работать медленнее и хочу в этом убедиться )

[evgwest]

улыбнуло)))) на миллионные доли секунды медленнее?) там объект-то малепусенький... это же просто обертка)

[Gunger]

Думаю, что разница будет чуть большей, чем миллионная доля секунды, однако, насчет несущественной разницы согласен )

[glib]

разница есть. пхп тратит много времени на разбор свойств класса и его методов. например, возьмите прототипы таблиц какой либо БД. В одном методе создайте прототипы для 100 таблиц в виде ассоциированных массивов (название колонки->значение). а в другом - каждой таблице создайте прототив объекта (класс с переменными для колонок и геттерами/сеттерами). тоже 100.
затем просто заинклудьте 100 файлов с массивами и посмотрите на время. а потом тоже самое с классами - отличие явное( хоть ООП и гибче(

[evgwest]

Класс для работы с сессиями через БД - примерно 40 строк кода. Набор того же функционала, но только на сессиях - столько же.
Интерпретация такого класса и таких функций займет примерно одинаковое кол-во времени. Зачем создавать какие-то прототипы и нагружать объект всяким мусором? А про инклуды - вообще нонсенс!!! Инклуды займут в несколько раз больше времени, нежели интерпретация класса. Это же обращение к диску!!!

[glib]

я привёл тут пример для опыта, чтобы проверить быстродействие пхп с обычным кодом и с классами, при похожем конечном результате в использовании...
Обращения к диску за инклуами можно отбить пхп-кэшами. например, АПР...

[nikitad]

Лучше для чего?

[Gunger]

Можно рассматривать примеры, как домашних страничек, так и крупномасштабных проектов.

[nikitad]

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

[Gunger]

Свои сессии — велосипед или обработчик стандартных сессий?

[Gunger]

Не пойму, тебе принципиально нужно заменить название сессии (session_name) или константу SID в PHP использовать с другой целью?

[Gunger]

А, понял, ты имеешь ввиду два сервера с разными /tmp директориями и, следовательно, различными сессиями, в целом. А чем не подходил вариант обертки, либо session_set_save_handler() ?

[Gunger]

Ээ.. Удивительно, не сталкивался с подобной проблемой.
И все равно интересно почему бы не использовать session_set_save_handler() ?

[evgwest]

он наверное имеет ввиду regenerate_sesssion_id которая никакого отношения к способу хранения сессий не имеет

[evgwest]

млин, комменты постятся не туда... это был ответ к 717937

[Mekras]

ИМХО, встроенные. Вообще, стараюсь последнее время по максимуму использовать встроенные средства. Компилированное в любом случае быстрее бегает чем интерпретируемое.
Не знаю, на чём споткнулся  fogx, но было бы очень интересно услышать подробности.
По поводу безопасности. Достаточно не класть в сессию конфиденциальную информацию.
По поводу страшных имён кук. Всё это регулируется стандартными средствами PHP.

[evgwest]

автор не копенгаген в теме)

[glib]

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

[MAnt]

Свой велосипед роднее ;) Использую свой родной, т.к знаю как он работает внутри и переписовать его под каждый проект не надо. А вообще, это вопрос привычки.

[Gunger]

Надеюсь, ты имеешь ввиду проекты, где единственный программист – ты. Согласись, что расширяемость проекта зависит именно от факторов использования стандартных реализаций. Я тоже, на данный момент, использую именно свой велосипед, но завел эту тему, чтобы убедиться в том, что мое склонение к использованию стандартной реализации сессий в обертке является верным.

[AlienZzzz]

Есть много того , что нужно еще написать , но писать свой обработчик сессий нет смысла.

[Postum]

Кадр из недавно опубликованной здесь презентации PHP&Perfomance (c) Ilia Alshanetsky

[red_pilot]

Закос под слоган, который был написан на главной станички руби на рельсах.

[Anatoly_Piskunov]

В таком случае ваш ник закос под RedHat. Не передергивайте.

[Damnedest]

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

Соответственно для этого единственный вариант переписывать session_save_handler

[DibrovLALALA]

я в шоке от голосования

[Gunger]

Неужели, ожидали противоположных результатов?

[npFly]

Я в шоке от комментов!!! 8| выбрал 2ой вариант так как считаю необходимимы иметь свой обработчик сессии. Есле есть база то хранить сессию в базе - так между прочим легко выяснить кто находитса в онлайн.