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

Question

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

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

например.

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

Если это так, я вижу выгоду. Однако это предполагает, что вы сохраняете openID пользователя в 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

Я могу вспомнить пару причин:

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

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

Answer 2

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

Answer 3

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

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

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

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