Devo retornar um código de status http 401 em um formulário de login baseado em html?


11

Devo retornar um código de status http 401 em um formulário de login baseado em html? A página é um formulário de login dedicado e não possui nenhum outro conteúdo significativo, apenas a estrutura do site. O URL, no entanto, pode ser para uma página que possui conteúdo significativo, mas requer login. Observe que essa configuração retorna apenas o código de status 401 e não solicita autenticação básica ao usuário.

Observando os padrões, parece que 401 é um código de status inadequado para formulários de login baseados em html. No entanto, nunca experimentei ou ouvi falar de quaisquer conseqüências ruins de fazê-lo.

Ao enviar 401, "A resposta DEVE incluir um campo de cabeçalho WWW-Authenticate (seção 14.47) contendo um desafio aplicável ao recurso solicitado."

requisito mencionado aqui:

http://tools.ietf.org/html/rfc2616#section-10.4.2

detalhado aqui:

http://tools.ietf.org/html/rfc2617#section-3.2.1

Sei que existem maneiras de contornar os mecanismos de pesquisa para convencê-los a indexar, ou não, páginas com base na presença de um formulário de login, mas eu prefiro usar códigos de status http, especificamente 401, pois sua definição parece uma combinação perfeita, se não for para o requisito de cabeçalho WWW-Authenticate.

Existe alguma razão para eu não usar o 401 neste caso? Semanticamente, existe alguma diferença entre não ser autorizado no nível http e ser autorizado no nível do aplicativo? Obviamente, você pode ter os dois, mas a autenticação no nível http não é apenas para facilitar a implementação no nível do aplicativo?

Respostas:


9

Como você observa, o RFC 2616 exige que uma resposta 401 seja acompanhada por um cabeçalho RFC 2617 WWW-Authenticate. Suponho que você possa cumprir tecnicamente esse requisito enviando um cabeçalho falso como:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

mas não tenho idéia do que os navegadores farão se forem apresentados com uma resposta 401, sem nenhum desafio que eles entendam. Eu supor que a maioria se não todos eles iria apresentar o corpo da solicitação para o usuário (como RFC 2616 diz que devem fazer se a autenticação falhar), mas nem RFC parece dizer explicitamente, para que eles possam legitimamente apenas mostrar uma mensagem de erro genérica em vez de.

Uma alternativa possível (se você não quiser usar apenas uma resposta de 200 como todo mundo parece fazer) seria usar um código de status 403 Proibido . Esse é um código de resposta amplamente usado e, até onde eu sei, quase todos os agentes de usuário interativos (ou seja, navegadores, em oposição a, digamos, mecanismos de pesquisa ou gerenciadores de download) devem reagir apresentando o conteúdo ao usuário, pelo menos se for longo o suficiente .

Embora a descrição do código de status 403 indique que "[a] autorização não ajudará", isso deve ser entendido na IMO como referência à autenticação RFC 2617 ou mecanismos similares de autorização no nível de protocolo; No que diz respeito ao navegador, não tem idéia se o envio de um formulário e o recebimento de um cookie em resposta contam como "autorização" ou outra coisa.

Um mecanismo mais comumente usado seria responder a solicitações não autenticadas com um redirecionamento temporário para uma página de logon separada, com a URL original passada como um parâmetro para que o usuário possa ser redirecionado novamente após a autenticação bem-sucedida. No entanto, observe que uma implementação ingênua pode permitir que uma pessoa mal-intencionada crie um link de login que redirecione o usuário para um URL arbitrário após o login. Se isso puder ser um problema de segurança, você deverá tomar medidas para evitá-lo, por exemplo, aceitando URLs de retorno que correspondam a um padrão seguro conhecido ou protegendo o URL de retorno com um código de autenticação de mensagens para evitar modificações.

De qualquer forma, se você estiver usando cookies HTTP para armazenar tokens de autenticação após o login, inclua um cabeçalho Vary em suas respostas (antes e depois da autenticação) para evitar o cache inadequado, como em Vary: Cookie.


2

Primeiro, se a página precisar de login, provavelmente você deve bloqueá-la pelo robots.txt

Segundo, se os robôs chegam à página, um erro 401 é adequado.


0

provavelmente, códigos de status podem ser úteis para não humanos [e para alguns navegadores? ]

independentemente pelo método de login, o cabeçalho correto deve ser enviado

por exemplo, no futuro, pode ser necessário escrever um cliente wrapper (não um navegador da web) que simplesmente se autentique apenas solicitando os cabeçalhos da página, não a totalidade do código html

você pode implementar seu aplicativo de login com os dois métodos, usando o mesmo banco de dados da lista de usuários

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.