¿Por qué formulario HTML redirección utiliza en OpenID 2?

Question

¿Por qué hacer un sistema automático de HTML post en lugar de una simple redirección?

Es de este modo que los desarrolladores pueden generar automáticamente un formulario de inicio de sesión que los puestos de directorio en el servidor remoto cuando el OpenID es conocido?

por ejemplo.

1. El usuario no está conectado y las visitas de tu página de inicio de sesión.
2. Detectar el usuario openID de una cookie.
3. El formulario se genera directamente puestos remotos OpenID server.
4. Servidor remoto redirige el usuario volver a la página web.
5. Sitio web de los registros en el usuario.

Si este es el caso, puedo ver el beneficio.Sin embargo, esto supone que el usuario del openID en una cookie cuando se salga de la sesión.

Me pueden encontrar muy poca información sobre cómo esta especificación debe ser mejor implementado.

Ver FORMULARIO HTML Redirección en las especificaciones oficiales:

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

He encontrado esto de mirar el PHP OpenID Biblioteca (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

La motivación principal fue, como Marca Brackett, dice, los límites de carga de tamaño impuestas por el uso de redirecciones y OBTENER.Algunas implementaciones son lo suficientemente inteligentes como para utilizar sólo POST cuando el mensaje va por encima de un cierto tamaño, como sin duda hay desventajas a la técnica POSTERIOR.(Jefe de entre ellos, el hecho de que su botón de Atrás no funciona.) Otras implementaciones, como en el ejemplo de código citado, ir a por la simplicidad y coherencia, y dejar que la libertad condicional.

Answer 2

Se me ocurren un par de razones:

• Un mínimo de seguridad por oscuridad - es un poco más de trabajo para manipular POST envíos de OBTENER
• El almacenamiento en caché y volver a normas más restrictivas para el POST de CONSEGUIR.No estoy del todo seguro de que esto iba de la materia para el OpenID caso de uso, sin embargo.
• Los Bots no seguir el POST, pero la redirección.Esto podría afectar la carga del servidor.
• Los diferentes navegadores tienen diferentes max longitudes para las solicitudes GET - pero ninguno de ellos es tan grande como el POST.
• Algunos de los navegadores de advertir acerca de la redirección a otro dominio.También voy a avisar si vas a enviar CORREOS a un no-HTTPS url.
• Girando JavaScript, puedo tener una relativamente segura experiencia, y no estar en silencio redirigido a otro dominio.

No sé que alguno de estos son un slam-dunk razón para elegir POST - a menos que la cantidad de datos que se envían supera la cadena de consulta de la longitud de algunos de los principales navegadores.

Answer 3

Se utiliza el mismo enfoque para la SAML Navegador Web SSO perfil.Las principales motivaciones de uso de HTML Post de redirección son :

• Prácticamente ilimitada duración de la carga :en SAML la carga es un documento XML firmado con XMLDSig y codificado en base64.Es más grande que el habitual 1024 caracteres limitación de URL (una de las mejores prácticas para apoyar no sólo a los exploradores, pero intermediario dispositivos de red como Firewall, Proxy Inverso, Equilibrador de Carga así).

• W3C HTTP estándar dice que CONSIGUE es idempotente (la misma URL ser ejecutado varias veces siempre debe resultar en la respuesta de los mismos) y, en consecuencia, puede ser almacenada a lo largo del camino, mientras que el POST no es y debe llegar a la dirección URL de destino.Respuesta de un OpenID Formulario HTML POST o SAML Formulario HTML POST no debería estar en la memoria caché.Se debe llegar al objetivo con el fin de iniciar la sesión autenticada.

Se podría argumentar que el uso de un HTTP GET redirección podría funcionar bien desde la dirección URL de consulta siempre cambio y sería derecho es la práctica.Sin embargo, esta sería una solución de el estándar de la W3C, y por lo tanto, no debe ser una norma, sino una implementación alternativa cuando ambos extremos de acuerdo con ella.