PHP Lang
  1. PHP Lang
  3. POSTing для https не всегда работает
Intereting Posts
Добавление новой социальной сети в медиа-виджет через PHP – Неверная иконка, показывающая Неподдерживаемый драйвер в laravel 4 при использовании пакета laravel-oci8 Выполнить «меньше» из командной строки PHP w / Scrolling Наиболее эффективный способ передачи переменных PHP во внешний файл JavaScript (или jQuery) PHP проверяет числовое значение внутри цикла foreach с парами ключей и значений? Входные значения, потерянные при отправке формы с ошибками set multiple = 'false' в форме во многих отношениях symfony2 Как безопасно записывать данные JSON в файл с помощью PHP Проблемы с переносом оболочки PHP / GD в Imagick ошибка phpunit при тестировании реализации с инъецированными зависимостями Создание PDF с цифровой подписью Подключение к базе данных MySQL, размещенной на удаленном сервере Файлы, исчезающие в середине функции разместить несколько результатов в одном массиве Как остановить галерею javascript php на последнем или первом изображении?

POSTing для https не всегда работает

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

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

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

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

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

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

Редактировать:

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

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

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

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

Solutions Collecting From Web of "POSTing для https не всегда работает"

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

В Firefox: Инструменты -> Очистить личные данные -> Проверить кеш, файлы cookie и прошедшие проверку сеансы

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

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

Больше кода необходимо диагностировать.

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

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

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

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

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

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

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