Что за формат хранения данных сессии в PHP?

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

Согласен с Вашими опасениями.

Но есть несколько предпосылок, которые позволяют не бояться:
1. Данные не критические, могут и потеряться.
2. Данные изменяются только извне.
3. Данных мало (собственно, одно число).
4. Данные должны выглядеть как сессия: продлеваться, истекать, привязаны к конкретному номеру сессии.
5. Сессия хранится не файлах.

«4. Данные должны выглядеть как сессия: продлеваться, истекать, привязаны к конкретному номеру сессии.
5. Сессия хранится не файлах.»
— Какие-то противоречивые факты. Вам так не кажется?
Похоже у Вас ещё более извращённые подходы.

Эм… в чём противоречие?

Попробую по другому объяснить…

Идея того, что Вы хотите сделать (изменение сессии извне), не нова. Как только появились сессии в PHP, появились идеи изменять их из вне. Но почему этого никто не делает?
Во-первых, сессии не дают полного контроля — они могут сброситься или не сброситься.
Во-вторых, они созданы не для организации взаимодействия изначально. Существуют другие способы — кэш, БД и файлы.

Механизм сессий в PHP — это не хранилище само по себе, а реализация подхода Server Session State. А вот способы хранения данных сессии различны

— кэш, БД и файлы.

Поэтому в данном месте противоречия не вижу. А Вы?

Опасность прямого изменения сессии такая же как и открыть одновременно одну и ту же страницу, на которой изменяются данные сессии, несколько раз.

Сессия, сохранённая в кэше или БД, имеет совершенно другой механизм работы, чем обычная сессия, сохранёная в файлах. Если Вы про это.

Я уже не знаю, как Вам объяснить… Сессии изначально не созданы для внешнего изменения. А Вы пытаетесь гвозди микроскопом забивать.

Госпди, парни, неужели сложно прочитать вопрос? Явно же указано "session.serialize_handler=php", что является дефолтовым значением в PHP.

DevMan, точно. Как же я сразу не заметил пока вопрос писал?

VitaZheltyakov, сессия сохранённая в кэше или в БД из кода ничем не отличается кроме, собственно, обработчика, который запихивает данные или в кэш или в БД. И я уже сказал, что сессия у нас хранится не файлах.

Не надо сравнений. Они на меня не производят впечатления, потому что я могу сразу несколько контрсравнений привести: Топор — предназначен для рубки, но им можно прекрасно забивать гвозди, а на поверхности будет меньше вмятин. Собаки — хз для чего они изначально предназначены, но они и сапёры, и подрывники, и поводыри, и т.д… Виагра — изначально это лекарство было предназначено «для сердца», а сейчас Вы знаете для чего оно предназначено.

Cессия, сохранённая в кэше или в БД, отличается механизмами удаления. Cессия, сохранённая в кэше или в БД, это уже не совсем сессия, это алгоритм иммитирущий сессию.

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

p.s. Топором не прекрасно забивать гвозди.

Подводим итоги.

Cессия, сохранённая в кэше или в БД, это уже не совсем сессия, это алгоритм иммитирущий сессию.

Если это не сессия, значит я не нарушаю работу внутреннего механизма обычных сессий. Значит всё хорошо?

sectus, да забейте — это просто демагогия, не имеющая никакого отношения к вашему вопросу.

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

Если у Вас свой собственный механизм сессий

Строка session.serialize_handler=php у вас никаких мыслей не вызывает?
Честно, очень интересно.

VitaZheltyakov, механизм то собственный. Но в него попадают данные уже в сериализованном виде. Мне кажется, что Вы не знаете как работает session_set_save_handler.

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

Я? Не, не жалуюсь, там с сериализацией всё просто. При этом можно выбрать способ сериализации. В том числе и в формате WDDX. А это говорит о том, что с данными сессии можно вполне легально манипулировать извне.

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

А… может Вы думаете, что приложение будет изменять напрямую свои сессии? Так это не так. Есть два сайта. Сайт1 будет изменять сессию Сайт2. При этом Сайт2 ничего не будет знать об этом.