Всем привет
Возникла такая задача:
есть форма, посылающая данные в некий логин скрипт. Необходимо сделать промежуточную страницу, на которой произвести некие действия с посылаемыми данными (установить куки, проверить на валидность и тд), но что бы это было почти прозрачно для пользователя: то есть промежуточная страница в итоге автоматом должна выполнять логин в конечный скрипт.Можно конечно воспользоваться конструкцией типа
<script>auth.submit();</script> , но может быть есть еще пути?
А именно не хочется что бы на компьютере пользователя могла закешироваться эта промежуточная страница, поскольку в ней в скрытых полях формы в случае <script>auth.submit();</script> будут храниться логин и пароль, что не есть хорошо в смысле секурности
Я обычно для такого дела использую скрипт (PHP), который действует по схеме:1. Проверяет всё, что требуется.
2. Если нормально, то делает, что надо (устанавливает куки, например), и идет на редирект header("Location: $url"). Браузер никакого контента не получает, соответственно и кешировать нечего.
3. Если нет, то либо сам выводит страницу с ошибкой, либо тем же способом редиректит на нее, либо что-то там еще по ситуации.
см. еще мой пост и обсуждение нечто подобного здесь: http://www.opennet.me/openforum/vsluhforumID8/3092.html#7 - может пригодиться.
>Я обычно для такого дела использую скрипт (PHP), который действует по схеме:
>
>
>1. Проверяет всё, что требуется.
>
>2. Если нормально, то делает, что надо (устанавливает куки, например), и идет
>на редирект header("Location: $url"). Браузер никакого контента не получает, соответственно и
>кешировать нечего.
>
>3. Если нет, то либо сам выводит страницу с ошибкой, либо тем
>же способом редиректит на нее, либо что-то там еще по ситуации.
>
>
>см. еще мой пост и обсуждение нечто подобного здесь: http://www.opennet.me/openforum/vsluhforumID8/3092.html#7 - может
>пригодиться.Счас попробую по такой схеме, но меня терзают смутные сомнения: в случае header - передадутся ли в финальный скрипт значения через POST?
>Счас попробую по такой схеме, но меня терзают смутные сомнения: в случае
>header - передадутся ли в финальный скрипт значения через POST?Пожалуй, возможны проблемы. В RFC 2068 (глава 10.3.2) читаем:
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
Вот интересно, а как обстоит дело с современными (HTTP/1.1) юзер-агентами?
>>Счас попробую по такой схеме, но меня терзают смутные сомнения: в случае
>>header - передадутся ли в финальный скрипт значения через POST?
>
>Вот интересно, а как обстоит дело с современными (HTTP/1.1) юзер-агентами?Интереса ради эксперементнул. И получил, что и M$IE, и MoFF ведут себя одинаково - при редиректе через Location посылают запрос GET независимо от того, какой был запрос изначально. Параметры POST-запроса теряются.
В принципе можно перегнать их в GET. Например так:
function getQueryStr ($reqArr, $prefix) {
$args = array();
foreach ($reqArr as $key => $value) {
if ($prefix != "") {
$key = $prefix . "[$key]";
}
if (is_scalar($value)) {
$args[] = urlencode($key) . "=" . urlencode($value);
} elseif (is_array($value)) {
$args[] = getQueryStr($value, $key);
} else {
$args[] = $key;
}
}
return implode("&", $args);
}header("Location: <YOUR_URL>?" . getQueryStr($_POST, ""));
Придумал с ходу - сильно не тестировал. Могут быть проблемы с длиной URL.
>>>Счас попробую по такой схеме, но меня терзают смутные сомнения: в случае
>>>header - передадутся ли в финальный скрипт значения через POST?
>>
>>Вот интересно, а как обстоит дело с современными (HTTP/1.1) юзер-агентами?
>
>Интереса ради эксперементнул. И получил, что и M$IE, и MoFF ведут себя
>одинаково - при редиректе через Location посылают запрос GET независимо от
>того, какой был запрос изначально. Параметры POST-запроса теряются.
>
>В принципе можно перегнать их в GET. Например так:
>
>function getQueryStr ($reqArr, $prefix) {
> $args = array();
> foreach ($reqArr as $key => $value) {
> if ($prefix != "") {
> $key = $prefix . "[$key]";
> }
> if (is_scalar($value)) {
> $args[] = urlencode($key) . "=" . urlencode($value);
> } elseif (is_array($value)) {
> $args[] = getQueryStr($value, $key);
> } else {
> $args[] = $key;
> }
> }
> return implode("&", $args);
>}
>
>header("Location: <YOUR_URL>?" . getQueryStr($_POST, ""));
>
>Придумал с ходу - сильно не тестировал. Могут быть проблемы с длиной
>URL.К сожалению нельзя. Смысл вот в чем: есть форма логина в почту на сайте, есть конечный скрипт, принимающий из этой формы значения параметров. Менять скрипт не хочу, поскольку как раз таки от этого и ухожу: в промежуточном скрипте надо будет "унифицировать" передаваемый логин для создания "правильного": с доменом, зависящим от того с какой страницы пользователь посылает данные. А так же в нем (в промежуточном) буду ставить куку для запоминания последнего введенного логина.
Поэтому бы и хотелось что бы промежуточный скрипт работал "прозрачно"...
>Поэтому бы и хотелось что бы промежуточный скрипт работал "прозрачно"...Созрели два варианта "прозрачного" решения.
1. Нечто вроде прокси. Промежуточный скрипт сам формирует и посылает HTTP-запрос к конечному скрипту, а результат запроса возвращает клиенту. Этот вариант наиболее безболезненый для клиента. Не требует JavaScript'а.
2. Хитрый финт ушами. При нажатии на кнопочку "Войти" форма не сразу отсылается куда надо, а сначала делается запрос промежуточному скрипту средствами JS без перезагрузки страницы. Промежуточный сгенерит недостающие данные и подставит их в форму или сообщит об ошибке. Если порядок, то после этого форма будет отослана конечному скрипту.
Ценные мысли можно почерпнуть отсюда:
Что-то всё мудрите, господа.
Пишешь скрипт, в который форма будет посылать данные.
Выполняешь необходимые действия.
Заполняешь необходимые значения переменных в $_POST или где там надо.
Далее просто инклудишь имеющийся скрипт.
>Далее просто инклудишь имеющийся скрипт.А что делать, если "имеющийся скрипт" находится на другом сервере?
Однако надеюсь, что это не наш случай. Если всё в пределах одного сервера, то такое решение действительно представляется самым простым и надежным.
Походу я не свосем корректно объяснил задачу:есть старница на неком сайте, с формой логина и пароля для входа в почту. Есть почтовый вэб интерфейс, в в логин скрипт которого и попадают на данный момент данные переданные из формы.
Для того что бы можно было поддерживать мультидоменность, но оставить пользователю возможность логиниться с "коротким" логином (без @domain.net) в принимающем скрипте были сделаны некоторые модификации (типа $login = $login . '@' . $domain) Это не есть хорошо, поскольку версии вэб морды переодически обновляются и приходится не забывать после обновления снова модифицировать скрипты.Так же хочется сохранить в куках значение логина и выбранного домена пользователя, что бы ему не приходилось вводить эти данные при повторном заходе на страницу авторизации. Сделать это со страницы авторизации не получится, поскольку в момент POST уже все заголовки были посланы и кука не сядет, а модифицировать снова принимающий скрипт не хочу (да и работает он на другом поддомене)
Единственный вариатн пришедший мне в голову: это промежуточная страница в том же домене, что и страница авторизации, принимающая данные из формы, анализирующая их, сажающая куки, а так же превращающая две переменные $login и $ domain в одну, как раз того вида, который по умолчанию нужен принимающему скрипту на почтовой морде.
Следовательно: 1. надо принять на этой странице данные через POST (не проблема). 2. Что то с ними сделать (тоже не проблема) 3. Отправить пользователя в почтовый интерфейс, передав опять таки методом POST уже обработанные данные.
Опять таки - единственные вариатн который работоспособен в таком виде:
<?
$login = $_POST[login];
$domain = $_POST[domain];
$pass = $_POST[password]
$login = $login.'@'.$domain;// Посадить куку.
//Запретить кеширование.echo "<FORM id='auth' action='http://mail.domain.net/login.php' method=post>
<INPUT type=hidden name=login value='$login'>
<INPUT type=hidden name=pass value='$pass'>
<script>auth.submit();</script>
</FORM>";
?>В примерно таком варианте все работет, но смущает уже описанная потенциальная возможность сохранения этой промежуточной страницы на компьютере пользователя... Смущает именно из-за <INPUT type=hidden name=pass value='$pass'>
Вот такая вот ситуевина
Я же, кажется, ничего непонятного не написал...Ещё раз.
Пишешь скрипт: new_my_mega_login.php
Форма отправляет данные ему.Код скрипта
----------
<?
$_POST['login'].='@'.$domen; //Домен можно получать автоматом, анализируя $_SERVER['HTTP_REFERER'] или $_SERVER['HOST']//посадить куку и ещё что надо сделать
// и т.п. и т.д.//а теперь инклудим скрипт логина
include('/login.php'); //и этот скрипт будет работать уже с полным логином, т.к. берёт значения переменных из того же $_POST
?>
----------И нечего заморачиваться со всякими промежуточными страницами.
P.S. Вот Вы гонитесь за секретностью. А не пугает, что, например, тот же Firefox сохраняет POST и GET переменные всех открытых в табе страниц?
Я вот так восстановил свой пароль, просто пролистав историю назад.
Или не пугает, что POST шлётся plain текстом по сети?
>Я же, кажется, ничего непонятного не написал...
>
>Ещё раз.
>Пишешь скрипт: new_my_mega_login.php
>Форма отправляет данные ему.
>
>Код скрипта
>----------
><?
>$_POST['login'].='@'.$domen; //Домен можно получать автоматом, анализируя $_SERVER['HTTP_REFERER'] или $_SERVER['HOST']
>
>//посадить куку и ещё что надо сделать
>// и т.п. и т.д.
>
>//а теперь инклудим скрипт логина
>include('/login.php'); //и этот скрипт будет работать уже с полным логином, т.к. берёт
>значения переменных из того же $_POST
>?>
>----------Ага, и весь почтовый интерфейс тоже инклюдить в скрипт?
>
>И нечего заморачиваться со всякими промежуточными страницами.
>
>P.S. Вот Вы гонитесь за секретностью. А не пугает, что, например, тот
>же Firefox сохраняет POST и GET переменные всех открытых в табе
>страниц?
>Я вот так восстановил свой пароль, просто пролистав историю назад.
>Или не пугает, что POST шлётся plain текстом по сети?Не пугает, SSL нас спасет
>Ага, и весь почтовый интерфейс тоже инклюдить в скрипт?Достаточно будет проинклудить login.php, я думаю.
Зачем весь то?
Ведь lodin.php отвечает только за идентификацию и авторизацию пользователя в системе?
Т.е. проставляет метку, что такому sid соответствует этот юзер.
Остальные же задачи выполнит стандартный набор компонентов системы, пользуясь информацией полученой в результате работы login.php.Опишите остальную часть проблемы.
Т.е. кроме проставления куки и измения логина, какая задача на этом скрипте будет лежать?Или надо, чтобы этот скрипт, ещё отрабатывал при каждом обращении к почте (просмотр входящих, написание новых, удаление писем)?
Тогда делайте прокси скрипт, как описано выше товарищем XAnder'ом (пункт 1)
>есть старница на неком сайте, с формой логина и пароля для входа в почту.Может быть в этой форме повесить JavaScript'овый обработчик, который подправит поля формы как надо?
>>есть старница на неком сайте, с формой логина и пароля для входа в почту.
>
>Может быть в этой форме повесить JavaScript'овый обработчик, который подправит поля формы
>как надо?
Это не самое главное - хочется еще повесить куку в момент POST что бы потом не вводить логин домен....
>Это не самое главное - хочется еще повесить куку в момент POST
>что бы потом не вводить логин домен....Яваскриптом тоже можно ставить куку.
http://wboard.ru/topic329.html?pid=2023&mode=threaded&show=&...
>>Это не самое главное - хочется еще повесить куку в момент POST
>>что бы потом не вводить логин домен....
>
>Яваскриптом тоже можно ставить куку.
>http://wboard.ru/topic329.html?pid=2023&mode=threaded&show=&...Можно, но если я ничего не путаю, только до того как был послан хотя бы один байт текста. В моем случае - страница уже полностью прогружена, в момент нажатия Submit
>>Яваскриптом тоже можно ставить куку.
>>http://wboard.ru/topic329.html?pid=2023&mode=threaded&show=&...
>
>Можно, но если я ничего не путаю, только до того как был
>послан хотя бы один байт текста. В моем случае - страница
>уже полностью прогружена, в момент нажатия SubmitDr.Nebula, у меня подозрение, что ты по вышеуказанной ссылке не сходил, а если и сходил, то читал невнимательно. Там речь идет об установке куки полностью на стороне клиента и средствами клиента, то есть никаких "прогрузок" и "посылок байтов" не требуется.