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

Question

Почему вы делаете автоматический HTML-пост, а не просто перенаправление?

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

например.

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

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

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

См HTML FORM Перенаправление в официальной спецификации:

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; 
    } 
} 

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

• В стандарте HTTP W3C говорится, что GET является идемпотентным (один и тот же URL-адрес GET, выполняемый несколько раз, всегда должен приводить к одному и тому же ответу) и, следовательно, может быть кэширован по пути, в то время как POST не является и должен достигнуть целевого URL. Ответ на OpenID HTML-форму POST или SAML HTML-форму POST не следует кэшировать. Он должен достичь цели, чтобы инициировать аутентифицированный сеанс.

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