Назад | Перейти на главную страницу

Проблема с безопасным входом - Почему меня перенаправляют на небезопасный вход?

У меня проблемы с тем, чтобы на моем рабочем месте работал сайт. Проблема возникла, когда произошел «двойной вход» с сайта защищенного входа. На самом деле второй вход был предложен доменом HTTP, а не HTTPS.

По сути дела обстоят так:

Я немного смущен тем, почему пользователь не входит в систему правильно в первый раз (перенаправляется на не-ssl), но любой последовательный вход в систему будет в порядке? Я пытался использовать скрипач, чтобы увидеть, что происходит после того, как пользователь вводит свой пароль в первый раз, и пытался заставить скрипач автоматически входить на сайт (безуспешно)

Я считаю, что данный веб-сайт использует аутентификацию Basic Digest.

Спасибо за любую помощь

Похоже, что сервер передает заголовок Location на другую страницу во время (или сразу после) аутентификации.

В зависимости от того, как настроены серверы (для порта 80 и 443), страница также может быть просто закодирована для перехода на страницу http: // (порт 80), на которой вы еще не были аутентифицирован (опять же, в зависимости от структуры).

Можете ли вы проверить заголовок HTTP и сообщить, есть ли заголовок Location, или если кодировка аутентификации установлена ​​на «перенаправлять на страницу в случае успеха».

Базовая и дайджест-аутентификация заставляют браузер добавлять заголовок с именем Authorization. Сервер может читать или игнорировать его. Скорее всего, он проигнорирует его, если установлен файл cookie аутентификации. Этот файл cookie является файлом cookie сеанса. Он будет называться ASPSESSIONID, JSESSIONID, PHPSESSIONID или что-то подобное.

Вот что происходит:

  1. При первом входе в систему происходит сбой по HTTPS. Трудно сказать почему, я использую психическая отладка.
  2. Вы будете перенаправлены на страницу http. Сервер настроен на запрос базовой / дайджест-аутентификации, что и происходит.
  3. Вы вводите свои учетные данные, которые на этот раз принимаются. Сервер предоставляет вам файл cookie сеанса
  4. Возвращаясь к HTTPS, сервер игнорирует Authorization заголовок (который, скорее всего, завершится ошибкой), поскольку существует файл cookie сеанса.

Чтобы решить эту проблему, вы должны понять, почему первая аутентификация отклонена.

Fiddler - это прокси. Он не сможет увидеть зашифрованное содержимое страницы безопасного входа. Вам нужно добавить плагин в свой браузер, чтобы видеть заголовки HTTP. Если вы обновите свой вопрос заголовками, будьте осторожны. Обычная проверка подлинности - это ваш простой текстовый пароль в base64.