Pour une page Web qui existe, mais pour laquelle un utilisateur ne dispose pas des privilèges suffisants (il n'est pas connecté ou n'appartient pas au groupe d'utilisateurs approprié), quelle est la réponse HTTP appropriée à servir ?
401 Unauthorized ?403 Forbidden ?
Quelque chose d'autre ?
Ce que j'ai lu sur chacun d'eux jusqu'à présent n'est pas très clair sur la différence entre les deux. Quels sont les cas d'utilisation appropriés pour chaque réponse ?
Une explication claire de Daniel Irvine :
Il y a un problème avec 401 Non autorisé le code d'état HTTP pour les erreurs d'authentification. Et c'est bien cela : c'est pour l'authentification, pas pour l'autorisation. Recevoir une réponse 401, c'est le serveur qui vous dit "vous n'êtes pas vous n'êtes pas authentifié - soit pas du tout, soit incorrectement incorrectement, mais veuillez vous réauthentifier et réessayer." Pour vous aider, il inclura toujours un WWW-Authenticate qui décrit comment l'authentification.
Il s'agit d'une réponse généralement renvoyée par le serveur Web, et non par l'application Web. application web.
C'est aussi quelque chose de très temporaire ; le serveur vous demande de réessayer de réessayer.
Ainsi, pour l'autorisation, j'utilise le 403 Interdit réponse. C'est une réponse permanente, elle est liée à ma logique d'application, et c'est une réponse plus concrète plus concrète qu'une 401.
Recevoir une réponse 403, c'est le serveur qui vous dit : "Je suis désolé. Je sais qui vous êtes - je crois qui vous dites être - mais vous n'avez pas la l'autorisation d'accéder à cette ressource. Peut-être que si vous demandez gentiment à l'administrateur administrateur système, vous obtiendrez la permission. Mais s'il vous plaît, ne me dérangez plus jusqu'à ce que votre situation change."
En résumé, un 401 Non autorisé doit être utilisée en cas d'authentification manquante ou une mauvaise authentification, et une 403 Interdit La réponse doit être utilisée par la suite, lorsque l'utilisateur est authentifié mais n'est pas autorisé à effectuer l'opération demandée sur la ressource donnée.
Un autre format pictural agréable de la façon dont les codes d'état http doivent être utilisés.
Le message 403 par défaut d'IIS est "Ceci est une erreur 403 générique et signifie que l'utilisateur authentifié n'est pas autorisé à voir la page", ce qui semble convenir.
@JPReddy Votre réponse est correcte. Cependant, je m'attendrais à ce que le code 401 soit nommé "Unauthenticated" et le code 403 "Unauthorized". Il est très déroutant que la 401, qui concerne l'authentification, soit accompagnée du texte "Unauthorized"..... À moins que je ne sois pas bon en anglais (ce qui est fort possible).
@p.matsinopoulos votre interprétation de autorisé vs authentifié est correcte, il est en fait plus précis d'appeler 401 Non authentifié
Editar: RFC2616 est obsolète, voir RFC7231 y RFC7235 .
401 Non autorisé :
Si la demande comprenait déjà des informations d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations.
403 Forbidden :
Le serveur a compris la demande, mais refuse de l'exécuter.
D'après votre cas d'utilisation, il semble que l'utilisateur ne soit pas authentifié. Je renverrais 401.
Merci, ça m'a aidé à clarifier les choses. J'utilise les deux : la 401 pour les utilisateurs non authentifiés et la 403 pour les utilisateurs authentifiés dont les droits sont insuffisants.
Je n'ai pas voté à la baisse mais je trouve cette réponse assez trompeuse. 403 forbidden est plus approprié pour le contenu qui ne sera jamais servi (comme les fichiers .config dans asp.net). C'est soit ça, soit un 404. Je pense qu'il ne serait pas approprié de renvoyer 403 pour quelque chose qui est accessible mais pour lequel vous n'avez pas les bonnes informations d'identification.
"La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée." Il semblerait que si vous ne souhaitez pas utiliser une authentification de type HTTP, un code de réponse 401 n'est pas approprié.
Il manque quelque chose dans les autres réponses : il faut comprendre que l'authentification et l'autorisation dans le contexte de la RFC 2616 se réfèrent UNIQUEMENT au protocole d'authentification HTTP de la RFC 2617. L'authentification par des schémas en dehors de la RFC 2617 n'est pas prise en charge par les codes d'état HTTP et n'est pas prise en compte dans la décision d'utiliser 401 ou 403.
Unauthorized indique que le client n'est pas authentifié selon la norme RFC2617 et que le serveur lance le processus d'authentification. Forbidden indique soit que le client est authentifié selon la norme RFC2617 et n'a pas d'autorisation, soit que le serveur ne prend pas en charge la norme RFC2617 pour la ressource demandée.
Autrement dit, si vous avez votre propre processus de connexion et que vous n'utilisez jamais l'authentification HTTP, 403 est toujours la réponse appropriée et 401 ne doit jamais être utilisé.
Extrait de la RFC2616
10.4.2 401 Non autorisé
La demande nécessite une authentification de l'utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée. Le client PEUT répéter la demande avec un champ d'en-tête Authorization approprié (section 14.8).
et
10.4.4 403 Forbidden (Interdit) Le serveur a compris la demande mais refuse de l'exécuter. L'autorisation ne sera pas utile et la demande NE DEVRAIT PAS être répétée.
La première chose à garder à l'esprit est que l'"authentification" et l'"autorisation" dans le contexte de ce document font spécifiquement référence aux protocoles d'authentification HTTP de la RFC 2617. Ils ne font pas référence aux protocoles d'authentification personnalisés que vous avez pu créer en utilisant des pages de connexion, etc. J'utiliserai le terme "login" pour désigner l'authentification et l'autorisation par des méthodes autres que la RFC 2617.
La vraie différence n'est donc pas de savoir quel est le problème ou même s'il existe une solution. La différence est ce que le serveur attend du client pour la suite.
401 indique que la ressource ne peut pas être fournie, mais le serveur DEMANDE que le client se connecte via l'authentification HTTP et a envoyé des en-têtes de réponse pour lancer le processus. Il est possible qu'il y ait des autorisations qui permettent l'accès à la ressource, peut-être pas, mais essayons et voyons ce qui se passe.
403 indique que la ressource ne peut pas être fournie et qu'il n'y a, pour l'utilisateur actuel, aucun moyen de résoudre ce problème via la RFC2617 et qu'il est inutile d'essayer. Cela peut être parce que l'on sait qu'aucun niveau d'authentification n'est suffisant (par exemple à cause d'une liste noire d'IP), mais aussi parce que l'utilisateur est déjà authentifié et n'a pas d'autorité. Le modèle RFC2617 est celui d'un utilisateur et d'un justificatif d'identité, de sorte que le cas où l'utilisateur peut avoir un deuxième ensemble de justificatifs d'identité qui pourrait être autorisé peut être ignoré. Cela ne suggère ni n'implique qu'une sorte de page de connexion ou un autre protocole d'authentification non-RFC2617 peut ou ne peut pas aider - cela est en dehors des normes et de la définition de la RFC2616.
Alors que faire lorsque l'utilisateur demande une page qui nécessite une authentification non-http ? Envoyer le code d'état 403 ?
C'est important : "si vous avez votre propre processus de connexion et que vous n'utilisez jamais l'authentification HTTP, 403 est toujours la réponse appropriée et 401 ne doit jamais être utilisé".
@marcovtwout Envoyer un 302 à votre page de connexion, ou un 403 contenant un corps avec des informations comment se connecter ?
Selon RFC 2616 (HTTP/1.1) 403 est envoyé lorsque :
Le serveur a compris la demande, mais refuse de l'exécuter. L'autorisation ne sera pas utile et la demande NE DEVRAIT PAS être répétée. Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre publique la raison pour laquelle la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404 (Not Found) peut être utilisé à la place.
En d'autres termes, si le client PEUT accéder à la ressource en s'authentifiant, le code 401 doit être envoyé.
Et si ce n'est pas clair s'ils peuvent y accéder ou pas ? Disons que j'ai trois niveaux d'utilisateur - Public, Membres et Membres Premium. Supposons que la page soit réservée aux membres Premium. Un utilisateur public n'est pas authentifié et ne peut pas accéder à la page. pourrait être dans les catégories Membres ou Membres Premium lorsqu'ils se connectent. Pour le niveau d'utilisateur Membre, une 403 semblerait appropriée. Pour les membres Premium, la 401. Cependant, que servez-vous au public ?
Cela dépend de l'application, mais en général, si un utilisateur authentifié n'a pas les droits suffisants sur une ressource, vous pouvez fournir un moyen de changer les informations d'identification ou envoyer un 401. Je pense que le 403 est mieux adapté au contenu qui n'est jamais servi. En asp.net, il s'agit des fichiers web.config, des fichiers *.resx, etc. car quel que soit l'utilisateur qui se connecte, ces fichiers ne seront JAMAIS servis et il est inutile de réessayer.
+1, mais un +1 incertain. La conclusion logique est qu'un 403 ne devrait jamais être renvoyé, car un 401 ou un 404 serait une réponse strictement meilleure.
En supposant l'authentification HTTP ( WWW-Authenticate y Autorisation en-têtes) est en cours d'utilisation Si l'authentification d'un autre utilisateur permet d'accéder à la ressource demandée, le message 401 Unauthorized doit être renvoyé.
403 Forbidden est utilisé lorsque l'accès à la ressource est interdit à tout le monde ou limité à un réseau donné ou autorisé uniquement par SSL, peu importe, tant que cela n'est pas lié à l'authentification HTTP.
Si l'authentification HTTP n'est pas utilisée et que le service dispose d'un système d'authentification basé sur les cookies, comme c'est la norme de nos jours, un message 403 ou 404 doit être renvoyé.
En ce qui concerne la 401, ceci est tiré de RFC 7235 (Protocole de transfert hypertexte (HTTP/1.1) : Authentification) :
3.1. 401 Non autorisé
Le code d'état 401 (Unauthorized) indique que la demande n'a pas été appliquée parce qu'il manque des informations d'authentification valides pour la ressource cible. Le serveur d'origine DOIT envoyer un champ d'en-tête WWW-Authenticate (section 4.4) contenant au moins un défi applicable à la ressource cible. Si la demande comprend des informations d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations. . Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.1). Si la réponse 401 contient le même défi que la réponse précédente, et que l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors l'agent utilisateur DEVRAIT présenter la représentation jointe à l'utilisateur, car elle contient généralement des informations de diagnostic pertinentes.
La sémantique des 403 (et 404) a évolué au fil du temps. Ceci date de 1999 ( RFC 2616 ) :
10.4.4 403 Interdit
Le serveur a compris la demande, mais refuse de l'exécuter. L'autorisation ne sert à rien et la demande NE DEVRAIT PAS être répétée. Si la méthode de demande n'était pas HEAD et que le serveur souhaite rendre publique la raison pour laquelle la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404 (Not Found) peut être utilisé à la place.
En 2014 RFC 7231 (Protocole de transfert hypertexte (HTTP/1.1) : Sémantique et contenu) a changé le sens de l'année 403 :
6.5.3. 403 Interdit
Le code d'état 403 (Forbidden) indique que le serveur a compris la demande mais refuse de l'autoriser. Un serveur qui souhaite rendre publique la raison pour laquelle la demande a été interdite peut décrire cette raison dans les données utiles de la réponse (le cas échéant).
Si les informations d'authentification ont été fournies dans la demande, le serveur les considère comme insuffisantes pour accorder l'accès. Le client NE DOIT PAS répéter automatiquement la demande avec les mêmes informations d'identification. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes. Toutefois, une demande peut être interdite pour des raisons sans rapport avec les informations d'identification.
Un serveur d'origine qui souhaite "cacher" l'existence actuelle d'une ressource cible interdite PEUT à la place répondre avec un code d'état 404 (Not Found).
Ainsi, un 403 (ou un 404) peut maintenant signifier à peu près n'importe quoi. Fournir de nouvelles informations d'identification peut aider... ou pas.
Je pense que la raison pour laquelle cela a changé est que la RFC 2616 supposait que l'authentification HTTP serait utilisée alors qu'en pratique les applications Web d'aujourd'hui construisent des schémas d'authentification personnalisés en utilisant par exemple des formulaires et des cookies.
C'est intéressant. Sur la base du RFC 7231 et du RFC 7235, je ne vois pas de distinction évidente entre 401 et 403.
403 signifie "Je vous connais mais vous ne pouvez pas voir cette ressource". Il n'y a aucune raison de se tromper.
"Si la demande comprenait des informations d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.1)." Cependant, ensuite "4.2. Le champ d'en-tête 'Authorization' permet à un agent utilisateur de s'authentifier auprès d'un serveur d'origine". Il semble que dans la RFC7235, ils utilisent le terme "autorisation" comme s'il s'agissait d'une "authentification". Dans ce cas, il semblerait qu'un utilisateur authentifié mais non autorisé ne devrait pas recevoir un message 401, mais plutôt 403.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
594 votes
401 'Unauthorized' devrait être 401 'Unauthenticated', problème résolu !
94 votes
Je ne sais plus combien de fois mes collègues et moi sommes revenus sur stackoverflow pour cette question. Les normes HTTP devraient peut-être envisager de modifier les noms ou les descriptions de 401 et 403.
0 votes
En fait, je reçois une version différente de cette erreur, comme "os_authType was 'any' and an invalid cookie was sent". Je n'arrive donc pas à trouver comment résoudre ce problème. J'ai beaucoup cherché sur Google, j'ai trouvé des raisons mais je n'ai pas trouvé de solution.
3 votes
@Qwerty non, la nouvelle RFC7231 rend obsolète la RFC2616. 403 a une signification différente maintenant.
2 votes
@fishbone vous n'avez pas non plus noté que le code d'état 401 a été supprimé de cette RFC :D
1 votes
@fishbone il a été ajouté à cette proposition maintenant mais utilise un RFC différent maintenant 7235 tools.ietf.org/html/rfc7235#section-3.1
0 votes
@ChristopheRoussy là où ça devient confus c'est que 403 devrait être Unauthorized ! ;)
0 votes
Si cette proposition apporte des changements significatifs à la signification de 401 et 403, elle n'a aucune chance. La seule chose qu'ils doivent faire est de changer le nom et la documentation et il sera assez difficile de faire en sorte que tous les serveurs utilisent le nouveau nom. Nous avons déjà essayé de rendre obsolètes les standards du web et cela ne fonctionne pas. Le web est trop grand et évolue trop lentement.
0 votes
403 peut rester "interdit". Ce nom est suffisamment clair. C'est le 401 qui prête à confusion et qui devrait probablement être décrit comme "Non connecté".