403 Proibido vs 401 não autorizado respostas HTTP
https://stackoverflow.com/questions/3297048
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Para uma página da web que existe, mas para que um usuário não tem privilégios suficientes (eles não são registradas ou não, pertencem ao bom grupo de usuário), que é a adequada resposta HTTP para servir?
401 Unauthorized?
403 Forbidden?
Algo mais?
O que eu li em cada até agora não é muito clara sobre a diferença entre os dois.Que casos de uso são apropriadas para cada resposta?
Solução
Uma explicação clara sobre a partir de Daniel Irvine:
Há um problema com o 401 não autorizado, o código de status HTTP para erros de autenticação.E é apenas isso:é para autenticação, não de autorização.Recebendo uma resposta 401 é o servidor dizendo, "você não é autenticada–ou não autenticado ou autenticado incorretamente–mas, por favor, autenticar novamente e tente novamente." Para ajudá-lo, ele vai sempre incluir um WWW-Authenticate cabeçalho que descreve como para se autenticar.
Esta é uma resposta geralmente retornado pelo servidor web, não sua web aplicação.
É também algo muito temporário;o servidor está pedindo a você para tentar novamente.
Assim, para autorização de uso a 403 Proibido resposta.É permanente, é presa à minha a lógica da aplicação, e de uma forma mais concreta resposta de um 401.
Receber um 403 resposta é o servidor de dizer, "sinto muito.Eu sei quem é você–eu acredito que você diga que você é, mas você simplesmente não tem permissão para acessar este recurso.Talvez se você perguntar o sistema administrador bem, você obterá permissão.Mas por favor, não se incomode me novamente até que a sua situação muda."
Em resumo, um 401 não autorizado a resposta deve ser usado para a falta de ou ruim de autenticação, e um 403 Proibido a resposta deve ser usado posteriormente, quando o usuário é autenticado, mas não está autorizado a para executar a operação solicitada em um determinado recurso.
Outro bom pictórica formato de como códigos de status http que deverá ser usado.
Outras dicas
Ver RFC2616:
401 não autorizado:
Se o pedido já incluído credenciais de Autorização, em seguida, a resposta 401 indica que a autorização tenha sido recusado por essas credenciais.
403 Proibido:
O servidor entendeu o pedido, mas está se recusando a cumpri-la.
Atualização
A partir de seu caso de uso, parece que o usuário não está autenticado.Eu iria voltar 401.
Algo que as outras respostas estão ausentes é que deve ser entendido que a Autenticação e a Autorização no contexto da RFC 2616 refere-se SOMENTE a Autenticação HTTP-protocolo de RFC 2617.Autenticação por esquemas de fora da RFC2617 não é suportado em códigos de status HTTP e não são considerados ao decidir se usar 401 ou 403.
Breve e Concisa
Não autorizado indica que o cliente não é RFC2617 autenticado e o servidor está iniciando o processo de autenticação.Proibida indica que o cliente está RFC2617 autenticado e não ter autorização ou que o servidor não dá suporte RFC2617 para o recurso solicitado.
O que significa que se você tem o seu próprio rolo de seu próprio processo de início de sessão e nunca utilizar a Autenticação HTTP, 403 é sempre a resposta adequada e 401 nunca deve ser usado.
Detalhada e Em Profundidade
A partir de RFC2616
10.4.2 401 não autorizado
O pedido requer a autenticação do usuário.A resposta DEVE incluir um cabeçalho WWW-Authenticate de campo (seção 14.47) contendo um desafio aplicável para o recurso solicitado.O cliente PODE repetir o pedido com a adequada Autorização de cabeçalho de campo (seção 14.8).
e
10.4.4 403 Proibido O servidor entendeu o pedido, mas está se recusando a cumpri-lo.A autorização não vai ajudar e o pedido NÃO DEVE ser repetido.
A primeira coisa a ter em mente é que "Autenticação" e "Autorização" no contexto do presente documento referem-se especificamente para a Autenticação HTTP protocolos de RFC 2617.Eles não se referem a qualquer roll-your-own protocolos de autenticação que você pode ter criado usando páginas de login, etc.Quero usar o "login" para se referir a autenticação e autorização através de métodos que RFC2617
Assim, a verdadeira diferença não é o que o problema é ou mesmo se há uma solução.A diferença é que o servidor espera que o cliente fazer a seguir.
401 indica que o recurso não pode ser previsto, mas o servidor está SOLICITANDO que o cliente logon através de Autenticação HTTP e enviou cabeçalhos de resposta para iniciar o processo.Possivelmente existem autorizações que vai permitir o acesso ao recurso, possivelmente, não são, mas vamos dar uma chance e ver o que acontece.
403 indica que o recurso não pode ser previsto e não há, para o usuário atual, não há maneira de resolver isso através de RFC2617 e nenhum ponto em tentar.Isso pode ser porque é sabido que nenhum nível de autenticação é suficiente (por exemplo, devido a um IP de lista negra), mas pode ser porque o usuário já estiver autenticado e não tem autoridade.O RFC2617 modelo é um usuário, um credenciais para o caso onde o usuário pode ter um segundo conjunto de credenciais que podem ser autorizado pode ser ignorado.Ele não sugere nem implica que algum tipo de página de início de sessão ou outros não-RFC2617 protocolo de autenticação pode ajudar ou não - que está fora do RFC2616 normas e definição.
+-----------------------
| RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
+-----------------------
| |
NO | v YES
v +-----------------------
404 | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
or +-----------------------
401 | |
403 NO | | YES
3xx v v
401 +-----------------------
(404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...)
or +-----------------------
redirect | |
to login NO | | YES
| |
v v
403 OK 200, redirect, ...
(or 404: no reveal)
(or 404: resource does not exist if private)
(or 3xx: redirection)
Verifica se realiza, nesta ordem:
- 404 se o recurso é público e não existe ou 3xx redirecionamento
- Caso CONTRÁRIO:
- 401, se não conectado ou sessão expirou
- 403, se o usuário não tem permissão para acessar o recurso (arquivo, json, ...)
- 404 se o recurso não existe ou não está disposto a revelar qualquer coisa, ou 3xx redirecionamento
Não autorizado:Código de Status (401), indicando que o pedido exige autenticação, normalmente isso significa que o usuário precisa ser registrado (sessão).Usuário/agente desconhecido pelo servidor.Pode repetir com outras credenciais.NOTA:Isto é confuso como isso deve ter sido chamado de 'não autenticado' em vez de 'não autorizado'.Isso também pode acontecer após o login se sessão expirou.Caso especial:Pode ser usado em vez de erro 404 para evitar revelar a presença ou não presença de recursos (créditos @gingerCodeNinja)
PROIBIDO:Código de Status (403), indicando que o servidor entendeu o pedido, mas recusou-se a cumpri-la.Usuário/agente conhecido pelo servidor, mas tem credenciais insuficientes.A repetição de pedido não funciona, a menos que as credenciais alterado, o que é muito improvável, em um curto espaço de tempo.Caso especial:Pode ser usado em vez de erro 404 para evitar revelar a presença ou não presença de recursos (créditos @gingerCodeNinja)
NÃO ENCONTRADO:Código de Status (404), indicando que o recurso solicitado não está disponível.Usuário/agente conhecidos, mas o servidor não irá revelar nada sobre o recurso, não como se ele não existir.A repetição não vai funcionar.Este é um uso especial de 404 (github por exemplo).
Como mencionado pelo @ChrisH existem algumas opções para redirecionamento 3xx (301, 302, 303, 307, ou não, redirecionando a todos e usando um 401):
De acordo com a RFC 2616 (HTTP/1.1) 403 será enviada quando:
O servidor entendeu o pedido, mas está se recusando a cumpri-la.A autorização não vai ajudar e o pedido NÃO DEVE ser repetido.Se o método de solicitação não foi CABEÇA e o servidor deseja tornar público porque o pedido não foi cumprida, ele DEVE descrever o motivo para a recusa da entidade.Se o servidor não deseja disponibilizar essa informação para o cliente, o código de status 404 (Não Encontrado) pode ser usado em vez
Em outras palavras, se o cliente PODE ter acesso ao recurso de autenticação, 401 deve ser enviado.
Supondo que a autenticação HTTP (WWW-Authenticate e A autorização os cabeçalhos) está em uso, se a autenticação como outro usuário poderia conceder acesso para o recurso solicitado e, em seguida, 401 não autorizado deve ser devolvido.
403 Proibido é usado quando o acesso ao recurso é proibido para todos, ou restrita a uma determinada rede ou permitidas somente através de SSL, o que quer desde que não relacionadas a autenticação HTTP.
Se a autenticação de HTTP não está em uso e o serviço de um cookie de autenticação com base em esquema de como é a norma hoje em dia, em seguida, um 403 ou um 404, devem ser devolvidos.
Sobre 401, isto é a partir da RFC 7235 (Protocolo de Transferência de Hipertexto (HTTP/1.1):Autenticação):
3.1.401 não autorizado
O 401 (não autorizado) código de status indica que o pedido tem não foi aplicada devido à falta de credenciais de autenticação válidas para o recurso de destino.O servidor de origem DEVE enviar um Cabeçalho WWW-Authenticate de campo (Seção 4.4), contendo pelo menos um desafio aplicável ao recurso de destino. Se o pedido incluído credenciais de autenticação e, em seguida, a resposta 401 indica que a autorização tenha sido recusado por aqueles credenciais.O cliente PODE repetir o pedido com uma nova ou substituído cabeçalho de Autorização de campo (Seção 4.1).Se o 401 resposta contém o mesmo desafio, como antes da resposta, e o agente de usuário já tentou de autenticação pelo menos uma vez, então o agente de usuário DEVE apresentar fechado de representação para a usuário, uma vez que normalmente contém relevantes informações de diagnóstico.
A semântica de 403 (e 404) mudaram ao longo do tempo.Isto é, a partir de 1999 (RFC 2616):
10.4.4 403 Proibido
O servidor entendeu o pedido, mas está se recusando a cumpri-la.
A autorização não vai ajudar e o pedido NÃO DEVE ser repetido.
Se o método de solicitação não foi CABEÇA e o servidor deseja fazer
pública porque o pedido não foi cumprida, ele DEVE descrever o a razão para a recusa da entidade.Se o servidor não deseja disponibilizar essa informação para o cliente, o código de status 404
(Não Encontrado) pode ser usado em vez disso.
Em 2014 RFC 7231 (Protocolo de Transferência de Hipertexto (HTTP/1.1):Semântica e de Conteúdo) mudou o sentido de 403:
6.5.3.403 Proibido
Os 403 (Proibido) o código de status indica que o servidor entendeu o pedido, mas se recusa a autorizar.Um servidor que deseja tornar público porque o pedido foi proibido pode descrever essa razão na resposta carga (se houver).
Se as credenciais de autenticação foram fornecidas na solicitação, a
servidor de considera-los insuficientes para conceder acesso.O cliente
NÃO DEVE repetir automaticamente o pedido com o mesmo
credenciais.O cliente PODE repetir o pedido com o novo ou diferente credenciais.No entanto, um pedido pode ser proibida por razões
não relacionados ao credenciais.Um servidor de origem que pretende "esconder" a atual existência de um
proibida recurso de destino em vez disso, PODE responder com um código de estado de
404 (Não Encontrado).
Assim, um 403 (ou um 404) pode agora dizer sobre qualquer coisa.Proporcionando novas credenciais podem ajudar...ou talvez não.
Eu acredito que a razão pela qual esta foi alterado é o RFC 2616 assumido HTTP autenticação será usado quando, na prática, a Web de hoje de aplicativos de compilação personalizada esquemas de autenticação usando, por exemplo, formulários e cookies.
- 401 não autorizado:Eu não sei quem você é. Este um erro de autenticação.
- 403 Proibido:Eu sei quem você é, mas você não tem permissão para acessar este recurso. Este é um erro de autorização.
Esta é uma velha questão, mas uma opção que nunca foi realmente trouxe foi para retornar um erro 404.A partir de uma perspectiva de segurança, o mais votado resposta sofre de um potencial o vazamento de informações vulnerabilidade.Digamos, por exemplo, que a página da web segura em questão é um sistema de administração da página, ou, talvez, mais comumente, é um registro em um sistema que o usuário não tem acesso.O ideal é que você não iria querer que um utilizador mal intencionado mesmo de saber o que há de página / registro, e muito menos que eles não têm acesso.Quando eu estou construindo algo como este, vou tentar gravar unauthenticate / solicitações não autorizadas em um registro interno, mas retornar um erro 404.
OWASP tem algumas mais informações sobre como um invasor pode usar esse tipo de informação como parte de um ataque.
Esta pergunta foi feita há algum tempo, mas de pensar das pessoas, move-se.
Seção 6.5.3 neste projecto (de autoria de Fielding e Reschke) dá-código de status 403 um significado um pouco diferente para o documentado no RFC 2616.
Ele reflete o que acontece na autenticação e autorização esquemas empregados pelos vários servidores da web e frameworks.
Eu já enfatizou a pouco eu acho que é mais salientes.
6.5.3.403 Proibido
Os 403 (Proibido) o código de status indica que o servidor entendeu o pedido, mas se recusa a autorizar.Um servidor que deseja tornar público porque o pedido foi proibido, pode-se descrever que a razão na resposta carga (se houver).
Se as credenciais de autenticação foram fornecidas na solicitação, o servidor considera-los insuficientes para conceder acesso. O cliente NÃO DEVE repetir o pedido, com as mesmas credenciais.O cliente PODE repetir o pedido com o novo ou credenciais diferentes. No entanto, um pedido pode ser proibida por razões não relacionadas com as credenciais.
Um servidor de origem que pretende "esconder" a atual existência de uma proibido recurso de destino em vez disso, PODE responder com um código de status 404 (Não Encontrado).
Qualquer que seja a convenção de usar, o importante é fornecer uniformidade em seu site / API.
TL;DR
- 401:Uma recusa que tem a ver com a autenticação
- 403:Uma recusa que não tem NADA a ver com a autenticação
Exemplos Práticos
Se apache requer autenticação (via .htaccess), e você bater Cancel, ele vai responder com um 401 Authorization Required
Se nginx localiza um arquivo, mas não tem direitos de acesso (usuário/grupo) para leitura/acesso-lo, ele irá responder com 403 Forbidden
RFC (2616 Seção 10)
401 não autorizado (10.4.2)
Significado 1: Necessita de se autenticar
O pedido requer a autenticação do usuário....
Significado 2: Autenticação insuficiente
...Se o pedido já incluído credenciais de Autorização, em seguida, a resposta 401 indica que a autorização tenha sido recusado por essas credenciais....
403 Proibido (10.4.4)
Significado: Não relacionados para autenticação
...A autorização não vai ajudar ...
Mais detalhes:
O servidor entendeu o pedido, mas está se recusando a cumpri-la.
Ele DEVE descrever o motivo para a recusa da entidade
O código de status 404 (Não Encontrado) pode ser usado em vez
(Se o servidor deseja manter esta informação do cliente)
eles não são registradas ou não, pertencem ao bom grupo de usuário
Você tem afirmado dois casos diferentes;cada caso deve ter uma resposta diferente:
- Se eles não são registrados em tudo o que você deve retornar 401 não autorizado
- Se eles são registrados, mas não pertencem ao bom grupo de usuários, você deve retornar 403 Proibido
Nota sobre o RFC com base nos comentários recebidos para esta resposta:
Se o usuário não estiver conectado, eles são não-autenticado, o HTTP equivalente do que é 401 e é erradamente chamado de não-autorizado na RFC.Como seção 10.4.2 estados 401 não autorizado:
"O pedido requer do usuário autenticação."
Se você não autenticado, 401 é a resposta correta.No entanto, se você estiver não autorizado, no semanticamente correto sentido, 403 é a resposta correta.
Em Inglês:
401
Você está potencialmente permitido o acesso, mas, por algum motivo, este pedido que você estava negado.Como uma palavra-passe incorrecta?Tente novamente, com a correta solicitação você vai obter uma resposta bem-sucedida em vez disso.
403
Você não é, nunca, permitido.O seu nome não estiver na lista, você não alguma vez entrar, ir embora, de não enviar uma re-experimentar o pedido, será recusada, sempre.Vá embora.
Estes são os significados:
401:O usuário não (corretamente) autenticado, o recurso de página/requer autenticação
403:Usuário autenticado, mas seu papel ou permissões não permite o acesso de recurso solicitado, por exemplo, o usuário não é um administrador e a página solicitada é para administradores
Isso é mais simples na minha cabeça do que em qualquer lugar aqui, então:
401:Você precisa HTTP basic auth para ver isso.
403:Você não pode ver isto, e o HTTP basic auth não ajuda.
Se o usuário só precisa se logar para usar o site padrão do HTML do formulário de login, 401 não seria adequado, porque ele é específico para o HTTP basic auth.
Eu não recomendo usar 403 para negar o acesso a coisas como /includes, porque tão longe como a web está em causa, esses recursos não existem e que devem, portanto, 404.
Isso deixa 403 como "você precisa ser registrado no".
Em outras palavras, 403 significa "este recurso requer alguma forma de autenticação HTTP basic auth".
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
Eu acho que é importante considerar que, para um navegador, 401 inicia um diálogo de autenticação para o usuário insira novas credenciais, enquanto 403 não.Navegadores de pensar que, se um 401 é devolvido, em seguida, o usuário deverá autenticar novamente.Assim 401 significa autenticação inválido, enquanto 403 significa uma falta de permissão.
Aqui estão alguns casos em que lógica onde um erro deve ser retornado de autenticação ou autorização, com frases importantes em negrito.
- Um recurso requer autenticação, mas sem credenciais foram especificado.
401:O cliente deve especificar as credenciais.
- As credenciais especificadas estão em um formato inválido.
400:Que nem 401 nem 403, como erros de sintaxe deve sempre retornar 400.
- As credenciais especificadas referência a um utilizador que não existe.
401:O cliente deve especificar credenciais válidas.
- Especificado credenciais são inválido mas especificar um usuário válido (ou não especificar um usuário se o usuário especificado não é necessário).
401:Novamente, o cliente deve especificar credenciais válidas.
- Especificado credenciais tem expirou.
401:Este é praticamente o mesmo que ter credenciais inválidas em geral, para que o cliente deve especificar credenciais válidas.
- As credenciais especificadas são completamente válidas, mas não basta particular recursos, porém, é possível que credenciais, com mais permissão pode.
403:Especificar credenciais válidas não iria conceder acesso para o recurso, como as credenciais atuais já estão em vigor, mas só não tem permissão.
- Particular recursos é inacessível independentemente das credenciais.
403:Isto é, independentemente das credenciais, para especificar credenciais válidas não pode ajudar.
- As credenciais especificadas são completamente válidos, mas a particular cliente é bloqueado a partir de usá-los.
403:Se o cliente estiver bloqueado, especificando novas credenciais não vai fazer nada.
Dado mais recente do RFC sobre o assunto (7231 e 7235) o caso de uso, parece bastante claro (grifo do autor):
- 401 é para não autenticado ("falta de autenticação válido");i.e.'Eu não sei quem você é, ou eu não confio em você é quem você diz que é.'
401 não autorizado
O 401 (não autorizado) código de status indica que o pedido não tem foi aplicada porque ele falta de autenticação válido credenciais para o recurso de destino.O servidor de geração de uma resposta 401 DEVE enviar um cabeçalho WWW-Authenticate de campo (Seção 4.1), contendo pelo menos um desafio aplicável ao recurso de destino.
Se a solicitação de autenticação de credenciais e, em seguida, o 401 resposta indica que a autorização tenha sido recusado por aqueles credenciais.O agente de usuário PODE repetir o pedido com uma nova ou substituído cabeçalho de Autorização de campo (Seção 4.2).Se o 401 resposta contém o mesmo desafio, como antes da resposta, e o agente de usuário já tentou de autenticação pelo menos uma vez, então o agente de usuário DEVE apresentar fechado de representação para a usuário, uma vez que normalmente contém relevantes informações de diagnóstico.
- 403 é para não autorizado ("se recusa a autorizar");i.e.'Eu sei quem você é, mas você não tem permissão para acessar este recurso.'
403 Proibido
Os 403 (Proibido) o código de status indica que o servidor entendido o pedido, mas se recusa a autorizar isso.Um servidor que deseja tornar público porque o pedido foi proibido, pode-se descrever que razão na resposta carga (se houver).
Se as credenciais de autenticação foram fornecidas na solicitação, a servidor de considera-los insuficientes para conceder acesso.O cliente NÃO DEVE repetir automaticamente o pedido com o mesmo credenciais.O cliente PODE repetir o pedido com o novo ou diferente credenciais.No entanto, um pedido pode ser proibida por razões não relacionados ao credenciais.
Um servidor de origem que pretende "esconder" a atual existência de um proibida recurso de destino em vez disso, PODE responder com um código de estado de 404 (Não Encontrado).
No caso de 401 vs 403, este foi respondida várias vezes.Este é essencialmente um 'pedido de HTTP ambiente debate, não uma 'aplicação' debate.
Parece ser uma pergunta sobre o roll-your-own-login problema (aplicação).
Neste caso, basta não ser registrado não é suficiente para enviar um 401 ou um 403, a menos que você use HTTP Auth vs uma página de login (não vinculado a definição HTTP Auth).Parece que você pode estar olhando para um "201 Criado", com um roll-your-own-tela de login presente (em vez de o recurso solicitado) para a aplicação de nível de acesso a um arquivo.Este diz:
"Eu ouvi que você está aqui, mas tente isso em vez (você não tem permissão para vê-lo)"
