Por que o redirecionamento de formulário HTML é usado no OpenID 2?

Question

Por que você faria uma postagem automática em HTML em vez de um simples redirecionamento?

Isso é para que os desenvolvedores possam gerar automaticamente um formulário de login que poste o diretório no servidor remoto quando o OpenID for conhecido?

por exemplo.

1. O usuário não está logado e visita sua página de login.
2. Você detecta o openID do usuário em um cookie.
3. É gerado um formulário que posta diretamente no servidor OpenID remoto.
4. O servidor remoto redireciona o usuário de volta ao site.
5. O site registra o usuário.

Se for esse o caso, posso ver o benefício.No entanto, isso pressupõe que você mantenha o openID do usuário em um cookie quando ele fizer logout.

Posso encontrar muito poucas informações sobre como essa especificação deve ser melhor implementada.

Veja Redirecionamento de FORM HTML nas especificações oficiais:

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

Eu descobri isso olhando para o Biblioteca PHP OpenID (versão 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

A principal motivação foram, como diz Mark Brackett, os limites de tamanho da carga útil impostos pelo uso de redirecionamentos e GET.Algumas implementações são inteligentes o suficiente para usar POST apenas quando a mensagem ultrapassa um determinado tamanho, pois certamente há desvantagens na técnica POST.(O principal deles é o fato de o botão Voltar não funcionar.) Outras implementações, como o código de exemplo que você citou, buscam simplicidade e consistência e deixam de fora essa condicional.

Answer 2

Posso pensar em alguns motivos:

• Um mínimo de segurança por obscuridade - é um pouco mais trabalhoso adulterar envios POST do que GET
• As regras de armazenamento em cache e reenvio são mais restritivas para POST do que para GET.Não tenho certeza se isso seria importante para o caso de uso do OpenID.
• Os bots não seguiriam o formulário POST, mas seguiriam o redirecionamento.Isso pode afetar a carga do servidor.
• Navegadores diferentes têm comprimentos máximos diferentes para solicitações GET - mas nenhum deles é tão grande quanto POST.
• Alguns navegadores avisarão sobre o redirecionamento para outro domínio.Eles também avisarão se você estiver enviando POST para um URL não HTTPS.
• Ao desligar o JavaScript, posso ter uma experiência relativamente segura e não ser redirecionado silenciosamente para outro domínio.

Não sei se algum desses é um motivo definitivo para escolher o POST - a menos que a quantidade de dados enviados exceda o comprimento da string de consulta de algum navegador importante.

Answer 3

A mesma abordagem é usada para o perfil SSO do navegador da Web SAML.As principais motivações para usar o redirecionamento de postagem HTML são:

• Comprimento praticamente ilimitado da carga útil:no SAML, a carga útil é um documento XML assinado com XMLDSig e codificado em base64.É maior do que a limitação usual de URL de 1.024 caracteres (uma prática recomendada para oferecer suporte não apenas a qualquer navegador, mas também a dispositivos de rede intermediários, como Firewall, Proxy reverso e Balanceador de carga).

• O padrão HTTP W3C diz que GET é idempotente (o mesmo URL GET executado várias vezes deve sempre resultar na mesma resposta) e, conseqüentemente, pode ser armazenado em cache ao longo do caminho, enquanto POST não é e deve atingir o destino da URL.A resposta de um formulário HTML OpenID POST ou SAML HTML Form POST não deve ser armazenada em cache.Ele deve atingir o destino para iniciar a sessão autenticada.

Você poderia argumentar que usar um redirecionamento HTTP GET também funcionaria, já que a consulta de URL sempre muda e você estaria certo, é prática.No entanto, isto seria uma solução alternativa para o padrão W3C e, portanto, não deveria ser um padrão, mas uma implementação alternativa sempre que ambos concordassem com ele.