POSTing to https form не всегда работает

Question

На моем сайте у меня простая форма входа. Страница обслуживается через HTTP, но URL-адрес POST формы - HTTPS.

Обычный метод заключается в том, что пользователь заполняет свое имя пользователя/пароль, форма отправляется (на полный URL-адрес HTTPS на том же сайте), а затем обработка POST перенаправляет 303 на домашнюю страницу пользователя , Но иногда этого не бывает.

Цикл (и это 100% повторяемостью) заключается в следующем:

1. Посещать форма Логин, заполнить детали и представить
2. На сервере скрипт Логин вызывается, проверяет данные, а затем, если все хорошо, перенаправляет 303 на домашнюю страницу пользователей.
3. Затем я выхожу на выход и затем выберет логин, после чего я вернусь в форму для входа
4. Затем я снова заполняю свои данные, нажимаю submit.
5. На этот раз логика входа в систему не выполняется (код отладки, который зарегистрировал логин на шаге 2, не вызван), и все же я все еще перенаправлен на домашнюю страницу пользователей. Но поскольку я не был успешно зарегистрирован, меня выгнали на первую страницу ...

Так почему же POST не всегда вызывает форму для входа? Я не думаю, что 303 кэшируется (и это не должно быть, согласно спецификации).

Глядя на журналы HTTPS на сервере, login.phpo вызывается в первый раз, но не второй ....

Edit:

Хорошо, мы решили эту проблему. Для тех, кто заинтересован:

Сайт работает на 2 веб-серверах за балансиром нагрузки. пользовательские сессии «липкие» - то есть, как только пользователь просматривает один веб-сервер, LB будет держать их «прикрепленными» к этому серверу. Это делается через файл cookie. Но как только мы переключаемся на HTTPS, LB не может читать cookie, поскольку соединение зашифровывается между браузером и веб-сервером. Таким образом, он чередовался между серверами. WWe имеет код для распространения аутентификации входа между веб-серверами, но этого не происходит достаточно быстро. Так что происходящее:

1. браузеры пользователей на сервере А, получает печенье говоря: «держать меня на А», заполняет их учетные данные для входа и хиты отправить
2. ЛБ, будучи не в состоянии расшифровать трафик HTTPS (и, следовательно, cookie), отправляет их в 50% случаев на B
3. B проверяет логин и устанавливает, что пользователь должен пройти аутентификацию в сеансе, прежде чем перенаправить пользователя на домашнюю страницу без https
4. Поскольку домашняя страница non https, LB считывает файл cookie и отправляет его в A, который ничего не знает об аутентификации, поскольку он не достаточно быстро распространяется от B ...

Решение заключалось в том, чтобы позволить LB расшифровывать трафик HTTPS, тем самым гарантируя, что пользователи действительно остаются на одном веб-сервере независимо от переходов HTTP/HTTPS.

Answer 1

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

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

Наконец, вы используете кеширование на стороне сервера? Я не думаю, что кэш-код opcode PHP проявил бы это поведение, но я видел более странные вещи с memcache (и, если вы используете фреймворк, каждая структура кэширует немного по-другому).

Answer 2

Как вы «выходите из системы» Вы пытались очистить свой кеш, чтобы увидеть, отбрасывают ли какие-либо оставшиеся переменные сеанса?

В Firefox: Инструменты -> Удалить личные данные -> Проверить кэш, куки и Авторизованные сессии

Answer 3

Я не думаю, что 303 кэшируются (и оно не должно быть, в соответствии со спецификацией) .. .

Нет, 303 не будет кэшироваться браузером, но некоторые другие уровни могут кэшировать его или другие страницы в последовательности. Кроме того, если вы используете файлы cookie для хранения состояния входа, вам необходимо убедиться, что вы устанавливаете «путь» и «домен», чтобы один и тот же файл cookie был установлен и удален, вместо нескольких скрытых копий для разных частей сайта ,

Дополнительный код, необходимый для диагностики.

Страница подается через HTTP, но URL-адрес POST формы - HTTPS.

Не делайте этого. Пользователь не может сказать, что URL-адрес действия будет HTTPS, не глядя на источник вручную (и проверяя каждый скрипт, на который ссылается), чего не должно произойти.

Таким образом, злоумышленник, находящийся в состоянии «человек в середине», может получить данные аутентификации, просто изменив начальную страницу HTTP с помощью формы входа. Это делает любую защиту на приемнике POST полностью спорным.

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