tipos - ¿Por qué se usa la redirección de formulario HTML en OpenID 2?

tipos de cajas de texto en html

Question

¿Por qué harías una publicación automática de HTML en lugar de una simple redirección?

¿Esto es así para que los desarrolladores puedan generar automáticamente un formulario de inicio de sesión que publique el directorio en el servidor remoto cuando se conoce OpenID?

p.ej.

1. El usuario no ha iniciado sesión y visita su página de inicio de sesión.
2. Detecta el openID del usuario desde una cookie.
3. Se genera el formulario que se envía directamente al servidor OpenID remoto.
4. El servidor remoto redirige al usuario al sitio web.
5. El sitio web inicia sesión en el usuario.

Si este es el caso, puedo ver el beneficio. Sin embargo, esto supone que mantiene el ID de usuario abierto en una cookie cuando cierra la sesión.

Puedo encontrar muy poca información sobre cómo esta especificación debería implementarse mejor.

Ver Redirección de formulario HTML en las especificaciones oficiales:

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

Descubrí esto al mirar la Biblioteca PHP OpenID (versión 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

Puedo pensar en un par de razones:

• Un poco de seguridad por oscuridad - es un poco más de trabajo manipular las presentaciones POST que GET
• Las reglas de caché y reenvío son más restrictivas para POST que GET. Sin embargo, no estoy del todo seguro de que esto importe para el caso de uso de OpenID.
• Bots no seguiría el formulario POST, pero seguiría el redireccionamiento. Esto podría afectar la carga del servidor.
• Los diferentes navegadores tienen diferentes longitudes máximas para las solicitudes GET, pero ninguno de ellos es tan grande como POST.
• Algunos navegadores alertarán sobre la redirección a otro dominio. También te advertirán si estás enviando POST a una url que no es HTTPS.
• Al desactivar JavaScript, puedo tener una experiencia relativamente segura y no ser redirigido silenciosamente a otro dominio.

No sé si alguno de estos es una razón importante para elegir POST, a menos que la cantidad de datos que se envíen exceda la longitud de la cadena de consulta de algún navegador importante.

Answer 2

El mismo enfoque se usa para el perfil SSO del navegador web SAML. Las principales motivaciones para usar la redirección de Post HTML son:

• Longitud prácticamente ilimitada de la carga útil: en SAML, la carga útil es un documento XML firmado con XMLDSig y codificado en base64. Es más grande que la limitación habitual de 1024 caracteres de URL (una práctica recomendada no solo es compatible con navegadores sino también con dispositivos de red intermediarios como Firewall, Proxy inverso, Load Balancer).

• El estándar W3C HTTP dice que GET es idempotente (la misma URL GET ejecutada varias veces siempre debe dar como resultado la misma respuesta) y, en consecuencia, puede almacenarse en caché mientras POST no lo está y debe alcanzar el objetivo de la URL. Respuesta de un Formulario HTML de OpenID POST o SAML El formulario HTML POST no debe almacenarse en caché. Debe alcanzar el objetivo para iniciar la sesión autenticada.

Podría argumentar que el uso de una redirección HTTP GET también funcionaría, ya que la consulta de la URL siempre cambia y usted estaría en lo cierto es la práctica. Sin embargo, esto sería una solución del estándar W3C, y por lo tanto, no debería ser un estándar sino una implementación alternativa cada vez que ambos extremos estén de acuerdo.

Answer 3

La principal motivación fue, como dice Mark Brackett, los límites en el tamaño de la carga impuesta mediante el uso de redirecciones y GET. Algunas implementaciones son lo suficientemente inteligentes como para usar solo POST cuando el mensaje supera un determinado tamaño, ya que sin duda existen desventajas para la técnica POST. (El principal de ellos es el hecho de que su botón Atrás no funciona). Otras implementaciones, como el código de ejemplo que citó, son sencillas y consistentes y dejan de lado ese condicional.