Pourquoi la redirection de formulaire HTML est-elle utilisée dans OpenID 2 ?

StackOverflow https://stackoverflow.com/questions/34623

  •  09-06-2019
  •  | 
  •  

Question

Pourquoi feriez-vous une publication HTML automatique plutôt qu’une simple redirection ?

Est-ce pour que les développeurs puissent générer automatiquement un formulaire de connexion qui publie le répertoire sur le serveur distant lorsque l'OpenID est connu ?

par exemple.

  1. L'utilisateur n'est pas connecté et visite votre page de connexion.
  2. Vous détectez l'openID de l'utilisateur à partir d'un cookie.
  3. Le formulaire est généré et publié directement sur le serveur OpenID distant.
  4. Le serveur distant redirige l'utilisateur vers le site Web.
  5. Le site Web enregistre l'utilisateur.

Si tel est le cas, je peux voir l’avantage.Cependant, cela suppose que vous conserviez l'openID de l'utilisateur dans un cookie lorsqu'il se déconnecte.

Je peux trouver très peu d'informations sur la meilleure façon de mettre en œuvre cette spécification.

Voir Redirection HTML FORM dans les spécifications officielles :

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

J'ai découvert cela en regardant le Bibliothèque PHP OpenID (version 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;
    }
}
Était-ce utile?

La solution

La principale motivation était, comme le dit Mark Brackett, les limites de taille de charge utile imposées par l'utilisation des redirections et de GET.Certaines implémentations sont suffisamment intelligentes pour n'utiliser le POST que lorsque le message dépasse une certaine taille, car la technique POST présente certainement des inconvénients.(Le principal d'entre eux étant le fait que votre bouton Retour ne fonctionne pas.) D'autres implémentations, comme l'exemple de code que vous avez cité, privilégient la simplicité et la cohérence et laissent de côté ce conditionnel.

Autres conseils

Je peux penser à plusieurs raisons :

  • Un minimum de sécurité par l'obscurité - c'est un peu plus de travail de falsifier les soumissions POST que GET
  • Les règles de mise en cache et de resoumission sont plus restrictives pour POST que pour GET.Cependant, je ne suis pas entièrement sûr que cela serait important pour le cas d'utilisation d'OpenID.
  • Les robots ne suivraient pas le formulaire POST, mais suivraient la redirection.Cela pourrait avoir un impact sur la charge du serveur.
  • Différents navigateurs ont des longueurs maximales différentes pour les requêtes GET - mais aucun d'entre eux n'est aussi grand que POST.
  • Certains navigateurs avertiront en cas de redirection vers un autre domaine.Ils vous avertiront également si vous soumettez un POST à ​​une URL non HTTPS.
  • En désactivant JavaScript, je peux bénéficier d'une expérience relativement sécurisée et ne pas être redirigé silencieusement vers un autre domaine.

Je ne sais pas si l'un de ces éléments constitue une raison incontournable de choisir POST - à moins que la quantité de données envoyées ne dépasse la longueur de la chaîne de requête pour certains navigateurs majeurs.

La même approche est utilisée pour le profil SSO du navigateur Web SAML.Les principales motivations de l’utilisation de la redirection HTML Post sont :

  • Longueur pratiquement illimitée de la charge utile :dans SAML, la charge utile est un document XML signé avec XMLDSig et codé en base64.Il est plus grand que la limite habituelle de 1 024 caractères de l'URL (une bonne pratique pour prendre en charge non seulement tous les navigateurs, mais également les périphériques réseau intermédiaires tels que le pare-feu, le proxy inverse et l'équilibreur de charge).

  • La norme HTTP du W3C indique que GET est idempotent (la même URL GET exécutée plusieurs fois devrait toujours entraîner la même réponse) et peut par conséquent être mise en cache en cours de route alors que POST ne l'est pas et doit atteindre l'URL cible.La réponse d’un formulaire POST HTML OpenID ou d’un formulaire HTML SAML POST ne doit pas être mise en cache.Il doit atteindre la cible pour pouvoir lancer la session authentifiée.

Vous pourriez affirmer que l’utilisation d’une redirection HTTP GET fonctionnerait également puisque la requête URL change toujours et vous auriez raison, c’est la pratique.Cependant, il s'agirait d'une solution de contournement de la norme W3C et ne devrait donc pas être une norme mais une implémentation alternative lorsque les deux extrémités l'acceptent.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top