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

Question

[Сергей Береснев]

Появилась необходимость работать с сохранёнными данными сессии напрямую.

В сессию кладу некоторые данные, например

$_SESSION['id'] = 100500;

В том месте где сохраняется сессия ожидаю увидеть:

id|i:100500;

, но получаю

Ilsl4dNDgOPRqC2FwZ-OxeBxcn1qtO6IbkFAEh1zfoQ.

.

В настройках стоит:
session.serialize_handler=php

Comments

[WebSpider]

Фреймворк используете? Kohana?

[Сергей Береснев]

Нет, нет. А почему Вы интересуетесь?

[WebSpider]

Она тоже по умолчанию шифрует сессию

Answer 1

[Melkij]

Поройтесь в сторону suhosin.session.* (особенно suhosin.session.encrypt, больно уж название намекающее)

Comments

[Mikhail Osher]

А я вспоминал, как этот *censored* сахозин называется =\

[Сергей Береснев]

suhosin.session.encrypt

похоже на правду, завтра попробую.

[Сергей Береснев]

Да, это оно. Спасибо.

Answer 2

[Алексей Журбицкий]

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

Comments

[Сергей Береснев]

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

Answer 3

[Виталий Желтяков]

Извращение какое-то…

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

Comments

[Сергей Береснев]

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

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

[Виталий Желтяков]

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

[Сергей Береснев]

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

[Виталий Желтяков]

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

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

[Сергей Береснев]

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

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

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

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

[Виталий Желтяков]

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

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

[DevMan]

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

[Сергей Береснев]

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

[Сергей Береснев]

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

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

[Виталий Желтяков]

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

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

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

[Сергей Береснев]

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

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

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

[DevMan]

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

[Виталий Желтяков]

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

[DevMan]

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

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

[Сергей Береснев]

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

[Виталий Желтяков]

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

[Сергей Береснев]

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

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

[Сергей Береснев]

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