Есть друг, который работал в одной фирме, фирма несколько раз «перехватывала» гос. заказы на гос. сайты. Честно сказать, меня немного удивила структура выполнения этих заказов. Казалось бы, всё просто: одна фирма делает дизайн, другая фирма занимается вёрсткой, третья насаживает на «свою» CMS и четвёртая обеспечивает тех.поддержку. Всё хорошо, да только эти фирмы практически не контактируют и, можно сказать, не знают друг о друге. Первая лепит дизайн (не им же верстать, а главное заказчика ублажить), вторая иногда офигивает от дизайна (например сайт резина и бекграунд градиентом по диагонали) и верстает как может, третья насаживает что получилось на CMS и четвертой достаётся самое вкусно, тех. поддержка сайта на ХЗ какой CMS, хз кем написанной, хз кем свёрстанной с хз чьим дизайном и хз где взять PSD этого дизайна в случае чего.
Возможно, не всегда так идёт выполнение заказа, это только несколько заказов о которых мне рассказал друг, имевший несчастье участвовать в этой цепи.
А может фирмы и сами виноваты…
При рестарте сервера, что происходит с файлами сессии?
5) Имеется ввиду хедеры Cache-control и Expire от 1981го года.
6) Зайдёте, если SID верно составлен.
1) код сам по себе без всякого пояснения не должен пихать своё в одну из ответственных частей проектов — заголовки.
2) дело не в том что он сохраняет в /tmp дело в том что он создаёт много файлов в сумме, которые, уменьшают производительность из-за своей многочисленности.
3) имею ввиду хранение на диске, взять для примера хранение данных на диске у eAccelerator — просто и быстро (не про данные в памяти).
4) я вспомнил про давний баг. Суть его, что сессия может стухнуть раньше указного времени.
5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
Вы, видимо, не использовали сессии помимо сессий PHP, ибо как, в Java, например, сессии сделаны намного лучше.
На мой взгляд, сессия в PHP сделана крайне ужасна.
При старте сессия в хедеры выставляет свой Cache-Control и Expire, жутко гадит на диск в temporary, это камень и в огород и чистильщика сессии. При большом посещении tmp просто засоряется до нельзя и при этом PHP каждый раз лезет в эту кучу что бы найти нужную сессию. Сейчас существует множество алгоритмов хранения данных на диске, почему бы не использовать их?
То есть всё время надо следить что бы сессия где-нибудь ещё не гадила.
Если из всех страниц сайта только на некоторых есть сессия то есть вероятность что при переходах на страницы без session_start сессия стухнет.
На основе претензий: почему session_start всегда должна быть до вывода данных? неужели нельзя считать SID из куки после начала вывода? Понимаю что ей ещё надо нагадить в хедеры, но если сессия стартуется только при некоторых условиях, приходится извращаться с ob_start.
Я уже не говорю об отсутствии безопасности. Если хочешь обезопасить сессию приходится всегда писать свою обвертку и в итоге обвёртка полностью заменяет сессию и тогда получаем ещё одну не используемую и не отключаемую функциональность.
Зачем анониму таскать SID? Таким образом каждый раз при анониме скрипт лезет в tmp и искать переменную авторизации в _SESSION, когда проверку авторизации можно было свести к проверке присутствия сессии.
С бордером толщиной >1px, думаю, могут появится проблемы.
P.S. То есть поддерживаю действия Google Corp.
P.P.S. SPAM — не банка тушёнки :)
Возможно, не всегда так идёт выполнение заказа, это только несколько заказов о которых мне рассказал друг, имевший несчастье участвовать в этой цепи.
А может фирмы и сами виноваты…
5) Имеется ввиду хедеры Cache-control и Expire от 1981го года.
6) Зайдёте, если SID верно составлен.
2) дело не в том что он сохраняет в /tmp дело в том что он создаёт много файлов в сумме, которые, уменьшают производительность из-за своей многочисленности.
3) имею ввиду хранение на диске, взять для примера хранение данных на диске у eAccelerator — просто и быстро (не про данные в памяти).
4) я вспомнил про давний баг. Суть его, что сессия может стухнуть раньше указного времени.
5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
Вы, видимо, не использовали сессии помимо сессий PHP, ибо как, в Java, например, сессии сделаны намного лучше.
При старте сессия в хедеры выставляет свой Cache-Control и Expire, жутко гадит на диск в temporary, это камень и в огород и чистильщика сессии. При большом посещении tmp просто засоряется до нельзя и при этом PHP каждый раз лезет в эту кучу что бы найти нужную сессию. Сейчас существует множество алгоритмов хранения данных на диске, почему бы не использовать их?
То есть всё время надо следить что бы сессия где-нибудь ещё не гадила.
Если из всех страниц сайта только на некоторых есть сессия то есть вероятность что при переходах на страницы без session_start сессия стухнет.
На основе претензий: почему session_start всегда должна быть до вывода данных? неужели нельзя считать SID из куки после начала вывода? Понимаю что ей ещё надо нагадить в хедеры, но если сессия стартуется только при некоторых условиях, приходится извращаться с ob_start.
Я уже не говорю об отсутствии безопасности. Если хочешь обезопасить сессию приходится всегда писать свою обвертку и в итоге обвёртка полностью заменяет сессию и тогда получаем ещё одну не используемую и не отключаемую функциональность.
Зачем анониму таскать SID? Таким образом каждый раз при анониме скрипт лезет в tmp и искать переменную авторизации в _SESSION, когда проверку авторизации можно было свести к проверке присутствия сессии.