Почему перенаправление HTML формы используется в OpenID 2?

StackOverflow https://stackoverflow.com/questions/34623

  •  09-06-2019
  •  | 
  •  

Вопрос

Зачем вам автоматический HTML -пост, а не простой перенаправление?

Является ли это таким образом, чтобы разработчики могли автоматически генерировать форму входа в систему, которая публикует каталог на удаленном сервере, когда OpenID известен?

например.

  1. Пользователь не вошел в систему и посещает вашу страницу входа в систему.
  2. Вы обнаруживаете OpenID пользователя из файла cookie.
  3. Форма генерируется, которая напрямую публикуется на удаленном OpenID -сервере.
  4. Удаленный сервер перенаправляет пользователя обратно на веб -сайт.
  5. Журналы веб -сайтов в пользователе.

Если это так, я вижу выгоду. Однако это предполагает, что вы держите пользователя открытым в файле cookie, когда он выходит из входа.

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

См. Перенаправление HTML в официальных характеристиках:

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

Я узнал об этом, глядя на PHP Openid Library (версия 2.1.1).

// Redirect the user to the OpenID server for authentication.
// Store the token for this authentication so we can verify the
// response.

// For OpenID 1, send a redirect.  For OpenID 2, use a Javascript
// form to send a POST request to the server.
if ($auth_request->shouldSendRedirect()) {
    $redirect_url = $auth_request->redirectURL(getTrustRoot(),
                                               getReturnTo());

    // If the redirect URL can't be built, display an error
    // message.
    if (Auth_OpenID::isFailure($redirect_url)) {
        displayError("Could not redirect to server: " . $redirect_url->message);
    } else {
        // Send redirect.
        header("Location: ".$redirect_url);
    }
} else {
    // Generate form markup and render it.
    $form_id = 'openid_message';
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(),
                                           false, array('id' => $form_id));

    // Display an error if the form markup couldn't be generated;
    // otherwise, render the HTML.
    if (Auth_OpenID::isFailure($form_html)) {
        displayError("Could not redirect to server: " . $form_html->message);
    } else {
        print $form_html;
    }
}
Это было полезно?

Решение

Основной мотивацией, как говорит Марк Брэкетт, ограничения на размер полезной нагрузки, налагаемые с использованием перенаправлений и получения. Некоторые реализации достаточно умны, чтобы использовать Post только тогда, когда сообщение превышает определенный размер, поскольку в технике Post, безусловно, есть недостатки. (Главным среди них является тот факт, что ваша кнопка на спине не работает.) Другие реализации, такие как приведенный вами пример код, выбирайте простоту и последовательность и оставляют это условным.

Другие советы

Я могу вспомнить несколько причин:

  • Служба безопасности по мрачному
  • Правила кэширования и повторного использования являются более ограничительными для поста, чем получить. Я не совсем уверен, что это будет иметь значение для варианта использования OpenID.
  • Боты не будут следовать форме поста, но будут следовать перенаправлению. Это может повлиять на загрузку сервера.
  • Различные браузеры имеют разные максимальные длины для получения запросов, но ни один из них не такой большой, как почта.
  • Некоторые браузеры предупреждают о перенаправлении в другой домен. Они также предупреждают, если вы отправляете сообщение в URL без HTTPS.
  • Выключив JavaScript, я могу иметь относительно безопасный опыт и не быть молча перенаправленным на другой домен.

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

Тот же подход используется для веб -браузера SAML SSO профиля. Основными мотивами использования перенаправления HTML Post являются:

  • Практически неограниченная продолжительность полезной нагрузки: в SAML полезная нагрузка представляет собой документ XML, подписанный с кодированным XMLDSIG и Base64. Он больше, чем обычное ограничение 1024 символов на URL (наилучшая практика для поддержки не только любых браузеров, но и промежуточных сетевых устройств, таких как брандмауэр, обратный прокси, балансировщик нагрузки).

  • W3c http standard говорит, что GET является идентифицированным (один и тот же URL -адрес выполняется несколько раз, всегда должен привести к тому же ответу) и, следовательно, может быть кэширован по пути, в то время как POST не является и должен достичь цели URL. Ответ открытой формы HTML или Post Form HTML не должен быть кэширован. Он должен достичь цели, чтобы инициировать аутентифицированный сеанс.

Вы могли бы утверждать, что использование HTTP Get перенаправление будет работать так же, как и URL -запрос всегда изменяется, и вы были бы правы, - это практика. Тем не менее, это был бы обходной путь стандарта W3C, и, следовательно, не должен быть стандартом, а альтернативной реализацией, когда оба заканчиваются с ним.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top