Perché viene utilizzato il reindirizzamento del modulo HTML in OpenID 2?

Question

Perché dovresti creare un post HTML automatico anziché un semplice reindirizzamento?

È così che gli sviluppatori possono generare automaticamente un modulo di accesso che pubblica la directory sul server remoto quando l'OpenID è noto?

per esempio.

1. L'utente non ha effettuato l'accesso e visita la pagina di accesso.
2. Rilevi l'openID dell'utente da un cookie.
3. Viene generato un modulo che invia direttamente al server OpenID remoto.
4. Il server remoto reindirizza l'utente al sito web.
5. Il sito Web accede all'utente.

Se questo è il caso posso vedere il vantaggio.Tuttavia ciò presuppone che tu conservi l'openID dell'utente in un cookie quando si disconnette.

Posso trovare pochissime informazioni su come questa specifica dovrebbe essere implementata al meglio.

Vedi Reindirizzamento FORM HTML nelle specifiche ufficiali:

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

L'ho scoperto guardando il Libreria OpenID PHP (versione 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 motivazione principale era, come afferma Mark Brackett, i limiti sulla dimensione del carico utile imposti utilizzando reindirizzamenti e GET.Alcune implementazioni sono sufficientemente intelligenti da utilizzare il POST solo quando il messaggio supera una certa dimensione, poiché la tecnica POST presenta sicuramente degli svantaggi.(Il principale tra questi è il fatto che il pulsante Indietro non funziona.) Altre implementazioni, come il codice di esempio che hai citato, puntano sulla semplicità e sulla coerenza e tralasciano il condizionale.

Answer 2

Mi vengono in mente un paio di ragioni:

• Un minimo di sicurezza grazie all'oscurità: manomettere gli invii POST rispetto a GET richiede un po' più di lavoro
• Le regole di memorizzazione nella cache e di reinvio sono più restrittive per POST che per GET.Tuttavia, non sono del tutto sicuro che ciò abbia importanza per il caso d'uso di OpenID.
• I bot non seguirebbero il modulo POST, ma seguirebbero il reindirizzamento.Ciò potrebbe influire sul carico del server.
• Browser diversi hanno lunghezze massime diverse per le richieste GET, ma nessuno di essi è grande quanto POST.
• Alcuni browser avviseranno il reindirizzamento a un altro dominio.Ti avviseranno anche se stai inviando POST a un URL non HTTPS.
• Disattivando JavaScript, posso avere un'esperienza relativamente sicura e non essere reindirizzato silenziosamente a un altro dominio.

Non so se nessuno di questi sia un motivo valido per scegliere POST, a meno che la quantità di dati inviati non superi la lunghezza della stringa di query per alcuni dei principali browser.

Answer 3

Lo stesso approccio viene utilizzato per il profilo SSO del browser Web SAML.Le motivazioni principali dell'utilizzo del reindirizzamento dei post HTML sono:

• Lunghezza praticamente illimitata del carico utile:in SAML il payload è un documento XML firmato con XMLDSig e codificato base64.È più grande della solita limitazione di 1024 caratteri dell'URL (una best practice per supportare non solo qualsiasi browser ma anche dispositivi di rete intermedi come Firewall, Reverse Proxy e Load Balancer).

• Lo standard HTTP W3C afferma che GET è idempotente (lo stesso URL GET eseguito più volte dovrebbe sempre risultare nella stessa risposta) e di conseguenza può essere memorizzato nella cache lungo il percorso mentre POST non lo è e deve raggiungere l'URL di destinazione.La risposta di un POST del modulo HTML OpenID o del POST del modulo HTML SAML non deve essere memorizzata nella cache.Deve raggiungere la destinazione per avviare la sessione autenticata.

Si potrebbe sostenere che anche l'utilizzo di un reindirizzamento HTTP GET funzionerebbe poiché la query URL cambia sempre e avresti ragione nella pratica.Tuttavia, questa sarebbe una soluzione alternativa allo standard W3C e, pertanto, non dovrebbe essere uno standard ma un'implementazione alternativa ogni volta che entrambe le estremità sono d'accordo con esso.