Warum wird in OpenID 2 die HTML-Formularumleitung verwendet?

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

  •  09-06-2019
  •  | 
  •  

Frage

Warum sollten Sie einen automatischen HTML-Beitrag anstelle einer einfachen Weiterleitung erstellen?

Ist dies so, dass Entwickler automatisch ein Anmeldeformular generieren können, das das Verzeichnis auf dem Remote-Server veröffentlicht, wenn die OpenID bekannt ist?

z.B.

  1. Der Benutzer ist nicht angemeldet und besucht Ihre Anmeldeseite.
  2. Sie erkennen die openID des Benutzers anhand eines Cookies.
  3. Es wird ein Formular generiert, das direkt an den Remote-OpenID-Server sendet.
  4. Der Remote-Server leitet den Benutzer zurück zur Website.
  5. Die Website meldet den Benutzer an.

Wenn das der Fall ist, sehe ich den Vorteil.Dies setzt jedoch voraus, dass Sie die openID des Benutzers in einem Cookie behalten, wenn er sich abmeldet.

Ich kann nur sehr wenige Informationen darüber finden, wie diese Spezifikation am besten implementiert werden sollte.

Siehe HTML-FORMULAR-Umleitung in den offiziellen Spezifikationen:

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

Ich habe das herausgefunden, als ich mir das angesehen habe PHP OpenID-Bibliothek (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;
    }
}
War es hilfreich?

Lösung

Die Hauptmotivation war, wie Mark Brackett sagt, die durch die Verwendung von Weiterleitungen und GET auferlegte Begrenzung der Nutzlastgröße.Einige Implementierungen sind intelligent genug, POST nur zu verwenden, wenn die Nachricht eine bestimmte Größe überschreitet, da die POST-Technik sicherlich Nachteile hat.(Die wichtigste davon ist die Tatsache, dass die Schaltfläche „Zurück“ nicht funktioniert.) Andere Implementierungen, wie der von Ihnen zitierte Beispielcode, legen Wert auf Einfachheit und Konsistenz und lassen diese Bedingung weg.

Andere Tipps

Ich kann mir mehrere Gründe vorstellen:

  • Ein Mindestmaß an Sicherheit durch Unklarheit – es ist etwas aufwändiger, POST-Übermittlungen zu manipulieren als GET
  • Caching- und Resubmit-Regeln sind für POST restriktiver als für GET.Ich bin mir jedoch nicht ganz sicher, ob dies für den OpenID-Anwendungsfall von Bedeutung wäre.
  • Bots würden nicht dem POST-Formular folgen, sondern der Weiterleitung.Dies könnte sich auf die Serverlast auswirken.
  • Verschiedene Browser haben unterschiedliche maximale Längen für GET-Anfragen – aber keiner von ihnen ist so groß wie POST.
  • Einige Browser geben bei der Weiterleitung zu einer anderen Domain eine Warnung aus.Sie werden auch gewarnt, wenn Sie einen POST an eine Nicht-HTTPS-URL senden.
  • Durch das Deaktivieren von JavaScript kann ich eine relativ sichere Erfahrung machen und werde nicht stillschweigend auf eine andere Domain umgeleitet.

Ich weiß nicht, dass einer dieser Gründe ein absoluter Grund ist, sich für POST zu entscheiden – es sei denn, die Menge der gesendeten Daten überschreitet die Länge der Abfragezeichenfolge für einige gängige Browser.

Der gleiche Ansatz wird für das SAML-Webbrowser-SSO-Profil verwendet.Die Hauptgründe für die Verwendung der HTML-Post-Umleitung sind:

  • Nahezu unbegrenzte Länge der Nutzlast:In SAML ist die Nutzlast ein XML-Dokument, das mit XMLDSig signiert und Base64-codiert ist.Es ist größer als die übliche URL-Beschränkung von 1024 Zeichen (eine bewährte Methode, um nicht nur alle Browser, sondern auch zwischengeschaltete Netzwerkgeräte wie Firewall, Reverse Proxy und Load Balancer zu unterstützen).

  • Der W3C-HTTP-Standard besagt, dass GET idempotent ist (das gleiche URL-GET, das mehrmals ausgeführt wird, sollte immer zur gleichen Antwort führen) und daher unterwegs zwischengespeichert werden kann, während POST dies nicht ist und das URL-Ziel erreichen muss.Die Antwort eines OpenID-HTML-Formular-POST oder SAML-HTML-Formular-POST sollte nicht zwischengespeichert werden.Es muss das Ziel erreichen, um die authentifizierte Sitzung zu initiieren.

Sie könnten argumentieren, dass die Verwendung einer HTTP-GET-Umleitung ebenfalls funktionieren würde, da sich die URL-Abfrage immer ändert, und Sie hätten Recht, wenn es um die Praxis geht.Dies wäre jedoch eine Problemumgehung des W3C-Standards und sollte daher kein Standard, sondern eine alternative Implementierung sein, sofern beide Seiten damit einverstanden sind.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top