Сессия теряется при невыясненных обстоятельствах

Silex

unitecsys
Сессия теряется при невыясненных обстоятельствах

Всем привет.

Проблема. Есть админская часть с авторизацией, которая естественным путем тестировалась на всевозможных ИЕ 5.0+ и разных версиях Windows, на разных каналах, провайдерах и т.п. До этого случая все работало. А случай - у одного заказчика столкнулись с просто-таки потрясающим багом: в его локалке (при доступе с любых компов из нее) теряется сессия при обращении к одной из страниц.

Самое интересное, что УРЛ страницы и способ ее формирования абсолютно идентичны другим страницам. Скажем, добавление и редактирование раздела отличаются только тем, что для редактирования еще идет выборка значений из БД и загрузка в тот же шаблон. Так вот редактирование - все нормально, добавление - сессии уже нет. Причем до момента логического разветвления "добавление/редактирования" в скрипте дело даже не доходит - авторизация проверяется раньше. Дальше еще интереснее. Нет авторизации - должно показываться окошко авторизации. А вместо этого перенаправляет на страницу с адресом http:///, при том что хидеры там не посылаются нигде... такое ощущение, что он сам каким-то чудом (???) отправляет форму на адрес http:// и потом браузер добавляет третий слеш (action с абсолютным путем загружается в шаблон из скрипта, а в шаблоне уже есть заготовка "http://").

Больше ничего сказать не могу - проблема осложняется тем, что воспроизвести баг не могу - приходится удаленно "рулить" по аське человеком заказчика, чтобы тот сообщал, что выводят контрольные точки, а его уже нет. Из особенностей заказчика - очень быстрый интернет, одинаковые машины и лицензионные английские ВинХР, ИЕ6.

Что это может быть? Принимаются любые, даже самые безумные предположения. Я уже с ума сойду скоро от этого глюка... :(
 

tony2001

TeaM PHPClub
Silex
>воспроизвести баг не могу
сам понимаешь - телепаты в отпуске.
какой PHP? какая ОС? какой Апач?
тот же код, с теми же настройками у вас нормально выполняется?
 

Silex

unitecsys
РНР 4.3.3, Linux, Apache/1.3.27

Да, не работает именно у них - как уже говорил, тестировали до этого везде, у нас и у предыдущих заказчиков все нормально (они физически на том же сервере хостятся в соседних папках).
 

Silex

unitecsys
StUV
В смысле заново залить скрипты? Даже не знаю, чем это может помочь...

Это может быть из-за того, что доступ к ресурсам идет СЛИШКОМ быстро? Я понимаю, что звучит глупо, но все-таки. Интернет там от той же фирмы, что и хостит сайт (Инфоком в Киеве). Может, Апач "не успевает" с такой скоростью что-то отдавать-принимать и получается такая ерунда... Тога почему такого никогда не было в нашей локалке?
 

tony2001

TeaM PHPClub
>Это может быть из-за того, что доступ к ресурсам идет СЛИШКОМ быстро?
Silex, а если Апач локально стоит, то вообще все должно перестать работать? =)
 

StUV

Rotaredom
в смысле - мог ли клиент что-то "подправить" в скриптах ?

> Апач "не успевает"...
видимо ты уже долго паришься, раз такие идеи в голову лезут =)))))
 

IntenT

SkyDiver
Silex
А может дело в какой-то стене у клиента? рубит куки, или еще что???
 

Silex

unitecsys
Вот именно "или еще что". Рубил бы куки - рубил бы везде. А тут именно на одной странице, которая принципиально идентична остальным.

Снова появилась возможность "удаленной манипуляции" человеком у заказчика. Поменял УРЛ страницы (изменил значение гет-пераметра) на случай какого-то ненормального кеширования - не помогло, та же ошибка.

Ну что еще... Компилированные шаблоны Смарти вычищал (кеширование пока не производится).
 

Silex

unitecsys
StUV
Нет, клиент ничего не мог подправить. Опять-таки, у нас и из других мест все работает.

IntenT
Думали уже... http://***.org.ua/admin/management/tree/?id=1&action=add - вряд ли... Тем более, что http://***.org.ua/admin/management/tree/?id=1&action=edit - у них все ок.

-~{}~ 18.03.04 18:10:

http://***.org.ua/admin/management/tree/?id=1&action=add2 - та же байда, ошибка...
 

Silex

unitecsys
tony2001
>а если Апач локально стоит, то вообще все должно перестать работать? =)
Тони, я уже не знаю, за что хвататься и каким программерским богам молиться :) Просто одна из подмеченных особенностей - провайдер инета и хостинга в одном лице.

-~{}~ 18.03.04 18:15:

IntenT
>может какой-нить адмунчер и рубит
http://***.org.ua/admin/management/news/?action=add - все нормально...

-~{}~ 18.03.04 18:17:

P.S. Шеф уже хочет отправить меня в командировку с системником :)
 

MiRacLe

просто Чудо
не знаю может поможет моя печальная история...про похожие закидоны всемогущей матрицы... ситуация немного похожая.. сделав сайт на локальном сервере ,отладили,залили на основной хостинг.... всё работает,всё красиво... но обнаружился неведомый глюк... переменная сессии (в "админке") $_SESSION['lang'] стала попросту теряться.... в первое что пришло в голову напарнику - виноват Optimizer... помолились богам,постучали в бубны,подудели на флейте из тазобедренной кости рыжей девственницы... - не помогло,залили неэнкоденные скрипты... а глюк и нене там... долго мучались,облазили инет,даже часть кода переписали.... в общем за нехваткой времени "временно" забили... и вот заливаем мы очередной сайт на хостинг и снова впираемся всё с тем же глюком.... тут уж не забьешь.... и начал я исследования... долго пытался выследить закономерность,чуть ли не через строку вставлял print_r($_SESSION)... на бубен вновь поглядывать стал недобро,мелодию шаманскую разгульную вспоминать...... но всё напрасно - не отпускала проклятая Матрица....приглянулся я ей видимо.... в общем "локализовали" баг - обычный html-файл в ифрейме.. из-за него беда горькая творится.... и что тут думать... php его не обрабатывает,файл совершенно обычный... ну в общем фик его знает... - обновил php на хостинге...настройки сделал абсолютно идентичными с установками сервера "локального"...ну и нифига ...Матрица всё так же методично пялила нас во все щели... (ух и дофига уже написал не правда ли? ;o) )

Когда нашёл причину чуть не плакал... - авторизация в админской части происходила следующим образом - если запрашивался файл из /admin/ (RewriteEngine бла-бла-бла и всё в index.php)- стартовала сессия.. в сессии - если не установлен язык интерфейса - устанавливался дефолтный... а причина - маааааленькая картинка вызываемая а том самом файле html... она попросту не закачалась... сглючил ftp-клиент или же проделки матрицы,теперь уж не важно....в общем её не было... в общем это ещё загадка почему переменная в сессии всё-таки "терялась" потому что по логике вещей...ну нету файла... ну из /admin/... ну стартанула сессия....НО переменная-то там уже есть...в общем матрица или руки кривые... но вот так 1x1.gif испортил мне жизнь...

ошибку и на первом "глючном" сайте оперативно пофиксил... - те же яйса...тока в профиль - тоже картинка...но уже другая...

В общем к чему весь этот длинный опус... - ЛОГИ Апача надо смотреть :) в тот самый момент когда всплывают мысли - обвинить во всём скорость инета - немедленно tail error_log ;o)
 

crocodile2u

http://vbolshov.org.ru
Конечно, разные бывают глюки... Хотя я так и не понял, как могла незагруженная на FTP картинка помешать работе сессии.

Если я правильно понял, сессия у тебя на всех страницах стартует из одного и того же php-скрипта. Но все же, проверь регистрацию переменных в сессии. У меня был как-то похожий "баг" (из-за собственного криворучия) - модуль рассылки новостей пользовался переменной сессии "subscribe". Эта переменная регистрировалась в модуле рассылки новостей. Понадобилось сделать рассылку новинок из каталога - ну я и пользуюсь себе той же переменной, смотрю - а нет ее...
 

ys

отодвинутый новичок
Silex

Может id сесси, который задан в session_name('name'); совпадает с каким-нибудь _GET параметром или с кукой какой-нибудь?
 

Silex

unitecsys
В логах Апача все чисто. Имя сессии ни с чем не совпадает. Начинаю коситься в сторону mod_rewrite...
 

MiRacLe

просто Чудо
crocodile2u я примерно могу объяснить почему картинка повлияла... загружается img src="несуществующая картинка"..
поскольку она несуществующая - выполняется скрипт /index.php(RewriteRule),поскольку скрипт в папке /admin (есть соответствующее условие) стартует сессия и проверяются сессионыые переменные.... это о том как она вообще повлияла,а вот вопрос о том почему всё же переменная одна(всего одна) "терялась" (остальные оставались нетронутыми) и по сей день загадка.... думаю это всё глюк Матрицы... а насчёт совпадения разного рода id.. в разных массивах это сказка про другое - я всегда пользуюсь $_массив['переменная'] дабы избежать непоняток,к тому же даже если (в моём случае) написать $lang = "неважно что"; от или же $_POST['lang'] = "что-нибудь" , от этого $_SESSION['lang'] ну никак не измениться...
 

Z@

Guest
у меня была один раз такая бага.
Была форма поиска, в ней было много полей и для удобства пользователеля значение каждого поля заносилось в куки. И когда юзер заполнив все поля нажимал поиск, отваливалась сессия. Оказалось что куков нельзя положить больше 22-25 штук (зависит от браузера). А если класть больше, то ранее положенные затираются. И получилось что первый кук был
PHPSESSIONID
а потом еще 20 куков и при добавлении еще одного кука, кук PHPSESSIONID успешно потирался и сессия пропадала. Хотя в этом случае непохоже что проблема в этом.
 

clevel

Новичок
тут не от количества зависит, а от их общей длины(имя+значение)...
доку смотрите...
 
Сверху