Форум PHP

Столкнулся с ранее невиданной проблемой:
в каталоге test запускаем файл и регистрируем в нем некую сессионную переменную, после чего переходим к другому файлу ЭТОГО ЖЕ каталога. Данные сессии, как и положено, сохраняются. Но если подняться на уровень вверх, данные сессии не видны. Что бы это могло быть?

А сессия там стартуёт ?

каждый файл начинается с
$sid=session_id();
if(!$sid){
session_start();
}

$sid всегда будет присвоен уникальный id, следовательно session_start() не запускается, поэтому ссесии не видны.

<?php $sid = session_id(); session_start(); ?>

>$sid всегда будет присвоен уникальный id, следовательно session_start() не запускается, поэтому ссесии не видны.

А я вот, перед тем, как такое написать, заглянул в мануал, и таки избежал пяти минут позора.
Мелочь, а приятно.

а что в мануале ? session_id всегда будет уникальный id если его нет то он его получит

Я не буду с Вами спорить.

session_id дает уникальное значение, если сессия установлена. Если сессия не начиналась, там будет пусто. Если бы я ошибался, мой код не работал бы нигде. А он работает на сотнях сайтов и десятках серверов. Но на одном сервере, по не известным мне причинам, это работает только внутри того каталога, в котором сессия началась. В другие каталоги данные сессии не передаются. Хостеры ничего вразумительного сказать не могут. Пришлось вместо сессия применить сессионные куки (куки, без указания времени). В куках я просто указал, что они действительны для всего сайта, а не только для текущего каталога.
Но вопрос остается в силе: почему сессии могут не работать в другом каталоге?

сессии работают в любом каталоге.

возникают сомнения на счёт сотни сайтов :)

если только там изменили переменную session.cookie_path , которая по умолчанию "/"
, или если одн ссылка была с www. , а другая без него

// вообще-то да
$sid = session_id();
должно быть после
session_start();

Почему бы просто не написать session_start();?

У меня на моем хостинге и только на нем вот какая штука бывает:

<? // ну тут где-нибудь стартуем сессию и все как обычно а дальше $_SESSION['a'] = $a; //тут дальше код какой-нить // а вот дальше самое интересное if(что-то тру) $a =0; // то что в скобках возвращает ложь но почему то сразу теряеться сессия то есть пропадает $_SESSION['a']

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

может у Вас там что-то не то с регстер_глобалс и/или session_register() понакручено?

Глобалс точно выключено а вот насчет session_register() - ни разу не пользовался

session_id() стартует сессию автоматически
в тот раз я заменил все куками. Но сегодня еще раз столкнулся с этим же гемороем. Хостерам нужно меньше школу прогуливать. session.save_path у них пустой оказался (думаю, первый геморой был таким же, но я, скорей всего, не обратил внимания, так как еще не знал, где рыть). Накидал, где нужно файлов php.ini с session.save_path=/tmp и все заработало. С пустым session.save_path сервер, очевидно, хранил сессии в том же каталоге и, в другом, естественно, они не работали.

>Накидал, где нужно файлов php.ini с session.save_path=/tmp и все заработало.
пардон... Вы теперь сессии храните в общем каталоге с другими клиентами этого хостинга?
Не страшно?

какое решение, по-вашему, будет лучше?

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

Наверно там всё же стоит прописать какой-то путь в рамках собственной эккаунтт-иерархии?
И может быть не стоило так уж крошить батон на хостера за незаполненное поле session path?

на счет батона все просто: не определив каталог для сессий, они создали ситуацию когда мусор сыпался где ни попадя. Кроме того, если б они понимали в настройках сервера больше чем я, они смогли бы ответить, почему сессии не сохраняются при смене каталога. А так, устав задавать им вопросы, я обращался на форум, мучил гугла и, не надя ответа, экспериментировал сам, пока не обнаружил причину.
На счет конкретного пути: я сравнивал конфигурацию нескольких хостингов. На тех, где с сессиями проблем небыло, стоял /tmp. Там, где было проблема, путь для сессий не был указан. По-этому, не мудрствуя лукаво и не видя ничего страшного в ПОТЕНЦИАЛЬНОЙ возможности (а где ее нет?), получить пароль к НЕИЗВЕСТНОМУ месту, при условии, что хостинг будет взломан именно в момент сессии (при том, что взлом хостинга несет проблемы независимо от сессий), я сделал так же, как на других серверах. Посмотрите, кстати, на своем сервере. Скорей всего вы увидите именно /tmp. Можно было бы прописать путь к своей папке. Но вероятность накопления мусора в ней была бы выше, чем в папках, настроенных хостерами. По идее, они должны следить за ними и чистить при всяких перезапусках и т. д.

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

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

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

Твою налево... Когда же до вас дойдет, что листинги нужно делать так, чтобы они помещались в экран по ширине... :-\\\

проблема в том что ширина у всех разная :)

это у кого какая ширина, у меня при 130% увеличении помещается, но читал на 170% :)
(1280x720 + 115%(110px/дюйм) + "подогнать по ширине" и 170% и в "опере")

Пока стандарт для разработки 1024Х768
И хотя это уже редкость, все же нужно учитывать, если хочется соответствовать.

>Твою налево... Когда же до вас дойдет, что листинги нужно делать так, чтобы они помещались в экран по ширине... :-\\\

Дак я так обчыно и стараюсь делать. У меня помещаеться даже очень хорошо еще и места куча остаеться(даже при ширине 1024 пикселя все норм)

Кстати как то страно что это вам только через пол-месяца взбелсио после того как было сообщение оставлено :)))))))))))))

да. Потому что повода не было - на коммуникаторе я открыл эту страницу только сегодня.
Я без повода не ругаюсь.
А ширина текста меряется в символах, а не в пикселах.
И 80 символов в строку - красная цена.

ну уж извините:) Для каммуникатора я высчитывать символы сидеть не буду, если у меня страница будет улезать или будет близка к краю, то я подгоню количество симоволов а так это уже просто абсурд :))))

Вам для коммуникатора их высчитывать никто и не предлагает.
Обычные традиционные требования к листингу таковы, что он должен нормально просматриваться и печататься. И 80 символов - оптимальная ширина строки для просмотра и печати.