Кэш, редиректы и авторизация в сессии

[INS]

Кэш, редиректы и авторизация в сессии

Согласен быть убитым, только перед смертью объясните всё-таки, а?. Поиск не помог.

Ключевые моменты построения проекта:

* Одна основная точка входа: index.php

* Обработка всех данных из форм: ua.php (user_actions) и обратный редирект header("Location: ".$_SERVER['HTTP_REFERER']);

* Переадресация ошибки 404 на index.php

* Авторизация в сессию

Проблема:

НЕКОТОРЫЕ (не все) юзеры не могут авторизоваться. Успешно проходят регистрацию, подтверждают регистрацию по мылу (т.е. в сущности система работает). Копание в проблеме установило, что у этих юзеров стоит прокси.

Правильная схема прохождения:

1. Юзер вводит логин/пароль и отправляет запрос на ua.php
2. Там производится проверка, данные о входе сохраняются в сессии
3. ua.php производит редирект обратно на страницу, с которой был сделан запрос
4. index.php (точнее, подмодули оного) на основе информации из сессии определяет что пользователь зашёл и выдаёт обновлённую версию страницы (с формой выхода, вместо формы входа грубо говоря)

У тех что не получается, схема получается такая:

1. Вводит логин пароль, отправляет запрос
2. Производится проверка. Данные СОХРАНЯЮТСЯ в сессии (проверено дебагом)
3. Производится редирект обратно.
4. index.php НЕ ОПРЕДЕЛЯЕТ что пользователь зашёл и выдаёт ту же самую страницу с формой входа.

При этом примечательно, что внизу на страничке я вывожу дату генерации страницы (PHP), она всё время меняется. Т.е. вроде бы и не кэш, а вроде бы и он, ибо проблема актуальна только у тех кто за прокси. Где теряется сессионная информация - непонятно! (ID сессии один и тот же, не меняется)



Дополнительно:

Эти строки стоят и в index.php и в ua.php

// prevent cache
header("HTTP/1.0 200 Ok");
header("Expires: Mon, 31 Dec 2000 00:00:00 GMT");
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . "GMT");



При выводе в HTML-код также вставляются:

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, no-store, must-revalidate">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">

====================

Чего делать? %( половина бета-тестеров проекта юзают нормально, вторая половина обламывается.. Кто нибудь сталкивался с таким?

 

[Фанат]

и обратный редирект header("Location: ".$_SERVER['HTTP_REFERER']);

это ты самостоятельно догадался до такой шикарной идеи, или подсказал кто?

-~{}~ 14.02.06 10:55:

Правильная схема прохождения:

где лог обмена НТТР заголовками?

-~{}~ 14.02.06 10:56:

Эти строки стоят и в index.php и в ua.php

зачем?

При выводе в HTML-код также вставляются:

зачем?

-~{}~ 14.02.06 10:59:

Переадресация ошибки 404 на index.php

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

 

[INS]

Автор оригинала: Фанат
это ты самостоятельно догадался до такой шикарной идеи, или подсказал кто?

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

где лог обмена НТТР заголовками?

А где его обычно берут? ) (сори, нужен ликбез)

зачем?

Чтоб не кэшировалось однако...

 

[SiMM]

> использую такой способ чтобы при обновлении страницы данные не переотправлялись.
HTTP_REFERER то зачем к этому приплетать? Давно уже пора знать, что:
а) его может и не быть вовсе
б) в нём может быть всё, что угодно
Юзай REQUEST_URI, если это то, что тебе нужно.

 

[Фанат]

А где его обычно берут?

PHP FAQ: Самые основы. Просмотр обмена HTTP заголовками

Чтоб не кэшировалось однако...

а что - сильно кэшируется?

 

[INS]

Автор оригинала: SiMM
> использую такой способ чтобы при обновлении страницы данные не переотправлялись.
HTTP_REFERER то зачем к этому приплетать? Давно уже пора знать, что:
а) его может и не быть вовсе
б) в нём может быть всё, что угодно
Юзай REQUEST_URI, если это то, что тебе нужно.

Ок. Как тогда? По моему всё логично, отправил-обработал-вернулся туда, откуда отправил. Может быть всё что угодно, но кроме собственных проблем тому кто туда это "что угодно" засунул ничего это не принесёт. Request_URI юзаю при обработке 404

 

[Фанат]

Ну, раз всё логично, то оставляй, как есть

 

[INS]

Автор оригинала: Фанат
Ну, раз всё логично, то оставляй, как есть

Звучит с налётом сарказма

Продолжая исследования проблемы... сделано два файлика:

test1.php :

<?
session_start();
echo "SID: ".session_id()."<br>";
echo "Session VAR: ".$_SESSION['var']."<br>";

?>
<form action="test2.php" method=post>
Введи чёнить: <input type=text name=a> <input type=submit><br>
<input type=checkbox name=redirect> авторедирект
</form>

и test2.php

<?
session_start();
$_SESSION['var']=$_POST['a'];
if($_POST['redirect']) {header("Location: test1.php"); exit;}
echo "SID: ".session_id()."<br>";
echo "VAR: ".$_POST['a']."<br>";
echo "Session VAR: ".$_SESSION['var']."<br>";
echo "<br><br><a href=\"".$_SERVER['HTTP_REFERER']."\">Вернуться и посмотреть результат</a>";
?>

ВСЁ РАБОТАЕТ. как с авторедиректом , так и просто с переходом по обратной ссылке.

 

[Фанат]

ну и прекрасно!
Раз всё работает, остаётся только порадоваться =)

 

[McSimm]

Может быть всё что угодно, но кроме собственных проблем тому кто туда это "что угодно" засунул ничего это не принесёт.

Прокси/фаерволы (некоторые по умолчанию, некоторые по прихоти администраторов) могут удалять (или изменять?) этот заголовок.

 

[INS]

Автор оригинала: Фанат
ну и прекрасно!
Раз всё работает, остаётся только порадоваться =)

Работают test1.php и test2.php ) а index.php и ua.php не работают %(

продолжаю разбираться..

 

[Фанат]

index.php и ua.php не работают %(

а зачем ты тогда нам рассказываешь про test1.php и test2.php
непонятно.

ты, по-моему, сам не знаешь, чего хочешь

 

[INS]

Автор оригинала: Фанат
а зачем ты тогда нам рассказываешь про test1.php и test2.php
непонятно.

ты, по-моему, сам не знаешь, чего хочешь

Что в принципе данный механизм рабочий, и ошибка где-то ещё. Ошибку нашёл.

Ошибка, как это обычно и бывает, вызвана банальной глупостью (скорее, невнимательностью). Оказалось что кэш и прочее тут совершенно ни при чём.

В сессии помимо всего прочего сохранял protection_code, являющийся зашифрованной комбинацией md5(логин.пароль.айпишник); так вот когда я его генерировал, я для айпиадреса использовал $_SERVER['REMOTE_ADDR'];, а при проверке - другую переменную грубо говоря $ip (которая не была равна remote_addr, а ещё и учитывала наличие прокси - x_forwarded_for). В случае если protection_code не совпадал, осуществлялось разлогинивание. Эх, глупость какая.

Топик в топку ) стыдно.

Просто реально за***лся