Комментарии 75
Просьба аргументировать свой выбор, плюсы-минусы.
использование session_set_save_handler(). Хотя вот нередко видел изобретенный велосипед, который держался на обычном функционале сессий...
Да, и правда, что может быть лучше сессий... Только защита диплома и диссертаций, наверное.
плюсы-минусы опишите.
совсем не представляю, зачем мне использовать другие решения. стандартные сессии вполне устраивают...
совсем не представляю, зачем мне использовать другие решения. стандартные сессии вполне устраивают...
Всю жизнь использовал стандартный функционал, пока однажды больно не споткнулся. Вот тогда-то и выяснилось, что 90% того, что написано в учебниках про сессии, в реальной жизни работает так, да не так.
В результате после переделки авторизации с учетом всех возможных проколов в безопасности (я-то наивный считал, что в PHP разработчики сами обо всем позаботились), выяснилось, что сессии вообще не понятно, зачем нужны. Все равно практически все приходится самому контролировать.
Но тогда же к счастью оказалось, что вместо сессий очень удобно использовать куки. Есть несколько простых шагов, которые позволяют вполне легко уберечься от большинства атак (кроме разве что XSRF - о них стоит заботиться отдельно), плюс очень существенно ускорить время работы скрипта.
Хотел даже написать об этом статью на хабре, но т.к. кармы у меня нет и никогда не было, пришлось воздержаться. Если будет интересно - я готов выслать кому-то в личку, опубликуете от своего имени, ну или еще как.
В результате после переделки авторизации с учетом всех возможных проколов в безопасности (я-то наивный считал, что в PHP разработчики сами обо всем позаботились), выяснилось, что сессии вообще не понятно, зачем нужны. Все равно практически все приходится самому контролировать.
Но тогда же к счастью оказалось, что вместо сессий очень удобно использовать куки. Есть несколько простых шагов, которые позволяют вполне легко уберечься от большинства атак (кроме разве что XSRF - о них стоит заботиться отдельно), плюс очень существенно ускорить время работы скрипта.
Хотел даже написать об этом статью на хабре, но т.к. кармы у меня нет и никогда не было, пришлось воздержаться. Если будет интересно - я готов выслать кому-то в личку, опубликуете от своего имени, ну или еще как.
Присылай в личку, опубликую с твоими копирайтами, разумеется.
Я сейчас как раз на этой теме заморочен – что лучше. И толковых аргументов нагуглить не могу, к сожалению.
Я сейчас как раз на этой теме заморочен – что лучше. И толковых аргументов нагуглить не могу, к сожалению.
Ты уже можешь - зайди в свой хабрацентр и создай топик - просто не помещай его в групповой блог.
Карму повысил. Ждем статью :)
поднял тебе карму. есть мисль - так почему ее дежрать при себе, если поделиться хочеш...
НЛО прилетело и опубликовало эту надпись здесь
какой смысл в твоей статье на главной и в rss, если её нельзя прочитать недрузьям из первого круга? держи минус в карму
свой блог заведи, нефиг зависеть от какой-то кармы
На сложных проектах — свой велосипед.
Когда время общей разработки измеряется месяцами, можно потратить полдня на написание и отладку велосипеда и избежать дальнейшего геморроя.
Как PHP всё делает фиг поймешь. Всё складывается в /tmp/, а насколько это безопасно зависит от квалификации админа сервера. Куки пихает со страшным именем, в зависимости от настроек еще может сначала сунуть SID в URL, а может и не сунуть, когда мусор вычистит неизвестно. И так далее и тому подобное.
Кроме того, я храню сессии в базе и могу привязывать к ним другие данные вроде статистики и логов. Со стандартным механизмом так не сделаешь.
Когда время общей разработки измеряется месяцами, можно потратить полдня на написание и отладку велосипеда и избежать дальнейшего геморроя.
Как PHP всё делает фиг поймешь. Всё складывается в /tmp/, а насколько это безопасно зависит от квалификации админа сервера. Куки пихает со страшным именем, в зависимости от настроек еще может сначала сунуть SID в URL, а может и не сунуть, когда мусор вычистит неизвестно. И так далее и тому подобное.
Кроме того, я храню сессии в базе и могу привязывать к ним другие данные вроде статистики и логов. Со стандартным механизмом так не сделаешь.
Вот у меня такие же аргументы в пользу собственного велосипедного обработчика, но, глянув на Хабру и Автокадабру я заметил странную разницу — на Хабре, судя по всему, используется собственный обработчик, а на Автокадабре — стандартный. Интересно, чем это вызвано, как мыслят разработчики в конкретных ситуациях.
Кстати, сейчас выяснил подробнее про настройки сессий — почти все минусы решаются либо напрямую установкой директив в php.ini, либо с помощью ini_set().
Кстати, сейчас выяснил подробнее про настройки сессий — почти все минусы решаются либо напрямую установкой директив в php.ini, либо с помощью ini_set().
Попробую не согласиться... Это только моё мнение, поэтому как уже оцените - ваша воля. Каждый раз, когда я раньше думал "мая лесапета будет круче" - садился и писал. Было большое чувство удовлетворённости по окончанию писюльки. Со временем обленился вкрай... И начала посещать мысль - "а нет ли готовых решений?". Ведь не даром разработчики во всём мире используют готовые библиотеки и компоненты. Например посмотрите на обилие контролов для ASP.Net и на их цены. цены кусаются а библиотек - валом....
Но что-то я отклонился. Так вот: вы только подумайте - "сколько у ПХП разработчиков (в частности компания Зенд) уже опыта в создании этого движка?" Неужели они за столь длительное время не закрыли дыры в таком частоиспользуемом элементе как Сессии? И неужели они не повышают его быстродействие?
Повторюсь, только моё мнение, что базовой функциональности сессий - с головой хватает для простых сайтов. А для сложных можно использовать как Мемкэш или БД, как уже упоминалось. Но ведь это тоже некоторым образом ограничевает разработчика в определённой области. Например, будете использовать только БД или только файлы и тд.
А почему бы не выбрать что-то среднее? Например создать "обёртку" для стандартной сессии? Написание обёртки и её отладка займёт всего пару часов. Может даже и час :) Но зато эта обёртка будет оценивать ключ для сохранение в сессию и, в зависимости от логики, "нужные" элементы пихать в базу, а не нужные хранить например в памяти... Даже не добираясь до файла. Ведь не все используют на прямую функции работы с МуСКуЛом? :)
А используя класс-обёртку как для доступа к бызе так и для сессии, а также и для других утилит - проект становится более объектно-ориентированным, а также гибким и легко-расширяемым.
session_set_save_handler - хорош, но это немного скрывает ООП, которое и так тяжело проявить в ПХП.
Спасибо, что дочитали эти мысли до данной строки)
Но что-то я отклонился. Так вот: вы только подумайте - "сколько у ПХП разработчиков (в частности компания Зенд) уже опыта в создании этого движка?" Неужели они за столь длительное время не закрыли дыры в таком частоиспользуемом элементе как Сессии? И неужели они не повышают его быстродействие?
Повторюсь, только моё мнение, что базовой функциональности сессий - с головой хватает для простых сайтов. А для сложных можно использовать как Мемкэш или БД, как уже упоминалось. Но ведь это тоже некоторым образом ограничевает разработчика в определённой области. Например, будете использовать только БД или только файлы и тд.
А почему бы не выбрать что-то среднее? Например создать "обёртку" для стандартной сессии? Написание обёртки и её отладка займёт всего пару часов. Может даже и час :) Но зато эта обёртка будет оценивать ключ для сохранение в сессию и, в зависимости от логики, "нужные" элементы пихать в базу, а не нужные хранить например в памяти... Даже не добираясь до файла. Ведь не все используют на прямую функции работы с МуСКуЛом? :)
А используя класс-обёртку как для доступа к бызе так и для сессии, а также и для других утилит - проект становится более объектно-ориентированным, а также гибким и легко-расширяемым.
session_set_save_handler - хорош, но это немного скрывает ООП, которое и так тяжело проявить в ПХП.
Спасибо, что дочитали эти мысли до данной строки)
Согласен, что 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'));
у нас в большом проекте сначала никто не задумывался использовать что-то другое кроме стандартной сессии... но навсяк случай сделали обёртку. так вот, одной сессий пользовались все модули системы и как фронтенд так и бекэнд, и впоследствии за пять минут (в обёртке перед сохранением в сессию изменялся ключ - добавлялся префикс модуля) получилось разграничить все модули и подчистить лишние, неиспользуемые данные...
Да... самое то было бы унаследовать интерфейс.
При всём моём глубочайшем уважении к компании Зенд, сходите в их багтрекер и посмотрите позволил ли их опыт закрыть все дыры.
Кроме того, дыры очень часто случаются не по вине пхп-разработчиков, а по вине админов серверов.
Кроме того, дыры очень часто случаются не по вине пхп-разработчиков, а по вине админов серверов.
дыры там появляются постоянно, но ведь писать свой велосипед разве не создавать новые баги? или вы считаете что ваш код будет полностью идеальным?
Во-первых, это будут мои дыры, в которых я виноват сам, которые я смогу исправить и там где я сам всё контролирую. Как я уже говорил, здесь проблема не столько в возможности существования конкретных дыр, а в том, что не до конца понятно, что и как работает.
Во-вторых, передо мной и зендовцами стоят разные задачи. Мне надо написать оптимальный для моего проекта результат, им универсальный для всех-всех-всех.
Во-вторых, передо мной и зендовцами стоят разные задачи. Мне надо написать оптимальный для моего проекта результат, им универсальный для всех-всех-всех.
они предоставляют вам простейший инструмент, набор аксиом, работа которых много раз обсуждалась и известно, что проще делать некуда... вы его усложняете своей логикой. а что будет, если вы усложните уже свою логику? или быть может тогда не стоит использовать ПХП а разрабатывать своё? ведь оно то точно лучше всех существующих будет))
Да нормально в PHP реализованы сессии. Куда складывать, какое давать имя сессии, передавать ли в GET, как часто чистить мусор и тд. — всё настраивается. Для простых проектов — то, что надо. Но когда нужно хранить данные в базе, производить какие-то дополнительные проверки или ещё чего, то легко делается надстройка (session_set_save_handler) и ваши скрипты даже изменять не придётся. ;)
На проектах с большой нагрузкой ИМХО лучшие связки:
save.handler = memcache, либо, для снижения риска потери данных сессии - самописный save.handler в БД + данные сессии кладутся в memcache
save.handler = memcache, либо, для снижения риска потери данных сессии - самописный save.handler в БД + данные сессии кладутся в memcache
Вариант, использующийся в UMI.CMS.
Вопрос к Вам – save.handler в виде отдельных функций или единым классом?
Вопрос к Вам – save.handler в виде отдельных функций или единым классом?
а какая разница??? если у вас процедурный подход... тогда функции, если ООП - соответственно, объекты
Разница есть. Я явно чувствую, что объектный вариант будет работать медленнее и хочу в этом убедиться )
улыбнуло)))) на миллионные доли секунды медленнее?) там объект-то малепусенький... это же просто обертка)
Думаю, что разница будет чуть большей, чем миллионная доля секунды, однако, насчет несущественной разницы согласен )
разница есть. пхп тратит много времени на разбор свойств класса и его методов. например, возьмите прототипы таблиц какой либо БД. В одном методе создайте прототипы для 100 таблиц в виде ассоциированных массивов (название колонки->значение). а в другом - каждой таблице создайте прототив объекта (класс с переменными для колонок и геттерами/сеттерами). тоже 100.
затем просто заинклудьте 100 файлов с массивами и посмотрите на время. а потом тоже самое с классами - отличие явное( хоть ООП и гибче(
затем просто заинклудьте 100 файлов с массивами и посмотрите на время. а потом тоже самое с классами - отличие явное( хоть ООП и гибче(
Класс для работы с сессиями через БД - примерно 40 строк кода. Набор того же функционала, но только на сессиях - столько же.
Интерпретация такого класса и таких функций займет примерно одинаковое кол-во времени. Зачем создавать какие-то прототипы и нагружать объект всяким мусором? А про инклуды - вообще нонсенс!!! Инклуды займут в несколько раз больше времени, нежели интерпретация класса. Это же обращение к диску!!!
Интерпретация такого класса и таких функций займет примерно одинаковое кол-во времени. Зачем создавать какие-то прототипы и нагружать объект всяким мусором? А про инклуды - вообще нонсенс!!! Инклуды займут в несколько раз больше времени, нежели интерпретация класса. Это же обращение к диску!!!
Лучше для чего?
Можно рассматривать примеры, как домашних страничек, так и крупномасштабных проектов.
В большинстве случаев хватает стандартных функций.
Как вариант - использовать собственный обработчик сохранения для того, что чтобы запихнуть их в БД, если сессий много и над ними постоянно совершаются какие-либо вычисления. То есть - какой-нибудь могучий модуль статистики на портале с большой посещаемостью.
Как вариант - использовать собственный обработчик сохранения для того, что чтобы запихнуть их в БД, если сессий много и над ними постоянно совершаются какие-либо вычисления. То есть - какой-нибудь могучий модуль статистики на портале с большой посещаемостью.
НЛО прилетело и опубликовало эту надпись здесь
Свои сессии — велосипед или обработчик стандартных сессий?
НЛО прилетело и опубликовало эту надпись здесь
Не пойму, тебе принципиально нужно заменить название сессии (session_name) или константу SID в PHP использовать с другой целью?
НЛО прилетело и опубликовало эту надпись здесь
А, понял, ты имеешь ввиду два сервера с разными /tmp директориями и, следовательно, различными сессиями, в целом. А чем не подходил вариант обертки, либо session_set_save_handler() ?
ИМХО, встроенные. Вообще, стараюсь последнее время по максимуму использовать встроенные средства. Компилированное в любом случае быстрее бегает чем интерпретируемое.
Не знаю, на чём споткнулся
fogx
По поводу безопасности. Достаточно не класть в сессию конфиденциальную информацию.
По поводу страшных имён кук. Всё это регулируется стандартными средствами PHP.
Не знаю, на чём споткнулся
fogxПо поводу безопасности. Достаточно не класть в сессию конфиденциальную информацию.
По поводу страшных имён кук. Всё это регулируется стандартными средствами PHP.
НЛО прилетело и опубликовало эту надпись здесь
Свой велосипед роднее ;) Использую свой родной, т.к знаю как он работает внутри и переписовать его под каждый проект не надо. А вообще, это вопрос привычки.
Надеюсь, ты имеешь ввиду проекты, где единственный программист – ты. Согласись, что расширяемость проекта зависит именно от факторов использования стандартных реализаций. Я тоже, на данный момент, использую именно свой велосипед, но завел эту тему, чтобы убедиться в том, что мое склонение к использованию стандартной реализации сессий в обертке является верным.
Есть много того , что нужно еще написать , но писать свой обработчик сессий нет смысла.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Кадр из недавно опубликованной здесь презентации PHP&Perfomance (c) Ilia Alshanetsky
НЛО прилетело и опубликовало эту надпись здесь
Вообще самое клевое - это хранить сессию в мемкеше... Мемкеш дает вам преимущества в скорости, возможность хранения сессий на разных серверах и т.п.
Соответственно для этого единственный вариант переписывать session_save_handler
Соответственно для этого единственный вариант переписывать session_save_handler
я в шоке от голосования
Я в шоке от комментов!!! 8| выбрал 2ой вариант так как считаю необходимимы иметь свой обработчик сессии. Есле есть база то хранить сессию в базе - так между прочим легко выяснить кто находитса в онлайн.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сессии – что лучше?