POSTing к форме https не всегда работает

Question

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

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

Цикл (и он повторяется на 100%) такой:

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

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

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

Изменить:

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Для диагностики требуется больше кода.

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

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

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

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

Answer 3

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

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

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