Dlaczego przekierowanie formularzy HTML jest używane w OpenID 2?

Question

Dlaczego miałbyś robić automatyczny post HTML zamiast prostego przekierowania?

Czy to umożliwia programistom automatyczne generowanie formularza logowania, który umieszcza katalog na serwerze zdalnym, gdy znany jest identyfikator OpenID?

np.

1. Użytkownik nie jest zalogowany i odwiedza twoją stronę logowania.
2. Wykrywasz identyfikator OpenID użytkownika z pliku cookie.
3. Generowany jest formularz, który bezpośrednio publikuje na zdalnym serwerze OpenID.
4. Serwer zdalny przekierowuje użytkownika z powrotem do witryny.
5. Strona loguje się do użytkownika.

W takim przypadku widzę korzyści. Jednakże zakłada to, że zachowujesz identyfikator użytkownika openID w pliku cookie po wylogowaniu.

Mogę znaleźć bardzo mało informacji na temat tego, jak najlepiej zaimplementować tę specyfikację.

See HTML FORM Przekierowanie w oficjalnych specyfikacji:

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

Znalazłem się od patrzenia na PHP OpenID Library (wersja 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

Główną motywacją było, jak mówi Mark Brackett, ograniczenie wielkości ładunku użytej przy użyciu przekierowań i GET. Niektóre implementacje są wystarczająco inteligentne, aby używać POST tylko wtedy, gdy wiadomość przekroczy określoną wielkość, ponieważ technika POST ma pewne wady. (Główną z nich jest fakt, że przycisk Wstecz nie działa.) Inne implementacje, takie jak przykładowy kod, który cytowałeś, idą na prostotę i konsekwencję i pomijają to warunkowo.

Answer 2

mogę myśleć z kilku powodów:

• odrobinę bezpieczeństwa przez zapomnienie - To nieco więcej pracy, aby manipulować zgłoszeń POST niż GET
• buforowanie i ponownie zasady są bardziej restrykcyjne dla POST niż GET. Nie jestem do końca pewien, czy to ma znaczenie dla przypadku użycia OpenID.
• Boty nie podążałyby za formularzem POST, ale byłyby zgodne z przekierowaniem. Może to wpłynąć na obciążenie serwera.
• Różne przeglądarki mają różne długości maksymalne dla żądań GET - ale żadna z nich nie jest tak duża jak POST.
• Niektóre przeglądarki ostrzegają o przekierowaniu do innej domeny. Ostrzegają też, jeśli przesyłasz POST pod adres URL inny niż HTTPS.
• Wyłączając JavaScript, mogę mieć względnie bezpieczne wrażenia i nie być przekierowywany do innej domeny.

Nie wiem, że którykolwiek z nich jest powodem, by wybrać POST - chyba że ilość wysyłanych danych przekracza długość kwerendy dla większej przeglądarki.

Answer 3

To samo podejście jest stosowane w profilu SSO przeglądarki Web SAML.Głównymi motywacje stosując przekierowanie HTML Post są:

• Praktycznie nieograniczona długość ładunku: ładunek w SAML jest dokumentem XML podpisany z XMLDSig i base64 zakodowany. Jest większy niż zwykłe ograniczenie adresu URL do 1024 znaków (najlepszą praktyką jest obsługa nie tylko przeglądarek, ale także pośredniczących urządzeń sieciowych, takich jak zapora ogniowa, serwer proxy odwrotnego dostępu, moduł równoważenia obciążenia).

• Standard HTTP W3C mówi, że GET jest idempotentem (ten sam URL, wykonywany wiele razy, powinien zawsze skutkować tą samą odpowiedzią) iw konsekwencji może być buforowany w czasie, gdy POST nie jest i musi osiągnąć docelowy adres URL. Odpowiedź formularza POST formularza HTML OpenID lub formularza HTML POST formularza Post nie powinna być buforowana. Musi dotrzeć do celu, aby zainicjować uwierzytelnioną sesję.

Można argumentować, że użycie przekierowania HTTP GET również działałoby, ponieważ zapytanie o adres URL zawsze się zmienia i masz rację, to praktyka. Byłoby to jednak obejście standardu W3C, a zatem nie powinno być standardem, ale alternatywną implementacją, ilekroć obydwie strony się z nią zgadzają.