voir RFC2616 :

401 non autorisé:

si la demande comprenait déjà des justificatifs d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces justificatifs.

403 Interdit:

Le serveur a compris la requête, mais refuse de la satisfaire.

mise à Jour

à Partir de votre cas d'utilisation, il apparaît que l'utilisateur n'est pas authentifié. Je vous rendrais la 401.

modifier: RFC2616 est obsolète, voir RFC7231 et RFC7235 .

ce qui manque aux autres réponses, c'est qu'il faut comprendre que L'authentification et L'autorisation dans le contexte de la RFC 2616 se réfère uniquement au protocole D'authentification HTTP de la RFC 2617. L'authentification par des schémas extérieurs à RFC2617 n'est pas prise en charge par les codes de statut HTTP et n'est pas prise en compte pour décider d'utiliser 401 ou 403..

brève et brève

non autorisé indique que le client n'est pas rfc2617 authentifié et le serveur lance le processus d'authentification. Forbidden indique soit que le client est rfc2617 authentifié et n'a pas d'autorisation, soit que le serveur ne supporte pas RFC2617 pour la ressource demandée.

ce qui signifie que si vous avez votre propre processus de connexion et que vous n'utilisez jamais L'authentification HTTP, 403 est toujours la bonne réponse et 401 ne devrait jamais être utilisé.

détaillé et en profondeur

de RFC2616

10.4.2 401 non autorisé

la requête nécessite une authentification de l'utilisateur. La réponse doit inclure un champ D'en-tête WWW-Authenticate (section 14.47) contenant une contestation applicable à la ressource demandée. Le client peut répéter la demande avec un champ d'en-tête D'autorisation approprié (section 14.8).

et

10.4.4 403 Interdit Le le serveur a compris la requête, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande ne doit pas être répétée.

la première chose à garder à l'esprit est que" authentification "et" autorisation " dans le contexte de ce document se réfèrent spécifiquement aux protocoles D'authentification HTTP de la RFC 2617. Ils ne font référence à aucun protocole d'authentification que vous avez créé en utilisant des pages de connexion, etc. J'utiliserai "login" pour faire référence à authentification et autorisation par des méthodes autres que RFC2617

donc la vraie différence n'est pas ce qu'est le problème ou même s'il y a une solution. La différence est ce que le serveur attend du client.

401 indique que la ressource ne peut pas être fournie, mais le serveur demande que le client se connecte par authentification HTTP et a envoyé des en-têtes de réponse pour lancer le processus. Éventuellement il y a des autorisations permettre l'accès à la ressource, peut-être il n'y en a pas, mais essayons de voir ce qui se passe.

403 indique que la ressource ne peut pas être fournie et il n'y a, pour l'utilisateur actuel, aucun moyen de résoudre ce problème à travers RFC2617 et aucun intérêt à essayer. Cela peut être dû au fait que l'on sait qu'aucun niveau d'authentification n'est suffisant (par exemple à cause d'une liste noire IP), mais cela peut être dû au fait que l'utilisateur est déjà authentifié et n'a pas d'autorité. Le RFC2617 modèle est celui de l'utilisateur, des informations d'identification pour le cas où l'utilisateur peut avoir un deuxième ensemble d'informations qui pourraient être autorisés peuvent être ignorés. Il 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-ce qui est en dehors des normes et de la définition RFC2616.

modifier: RFC2616 est obsolète, voir RFC7231 et RFC7235 .

Selon RFC 2616 (HTTP/1.1) 403 est envoyé lorsque:

Le serveur a compris la requête, mais refuse de la satisfaire. L'autorisation n'aidera pas et la demande ne doit pas être répétée. Si la méthode de requête N'était pas HEAD et que le serveur souhaite rendre publique la raison pour laquelle la requête n'a pas été satisfaite, il devrait décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas faire cette information disponible pour le client, le code d'état 404 (non trouvé) peut être utilisé à la place

en d'autres termes, si le client peut accéder à la ressource en s'authentifiant, il doit envoyer 401.

   GET, resource exists ?
    |      |
 NO |      | YES
    v      v
   404     Is authenticated (logged-in) ?
             |              |
          NO |              | YES
             v              v
             401            Can access resource (has permissions) ?
           (or: 404)        |            |
           or 301        NO |            | YES
           redirect         v            v
           to login        403           OK 200, 301, ...

les contrôles sont habituellement effectués dans cet ordre:

• 401 si non connecté ou session expirée
• 403 si l'utilisateur n'a pas la permission d'accéder à la ressource
• 404 si ressource non existante

non autorisé : code d'État (401) indiquant que la requête nécessite authentification , ce qui signifie habituellement que l'utilisateur doit être connecté (session). Utilisateur / agent inconnu du serveur. Pouvez répéter avec d'autres informations d'identification. NOTE: Ceci prête à confusion car cela aurait dû être nommé "non authentifié" au lieu de "non autorisé". Cela peut aussi échouer si la session est Expirée.

FORBIDDEN : code d'État (403) indiquant que le serveur a compris la requête mais a refusé de la satisfaire. Utilisateur / agent connu par le serveur mais a justificatifs d'identité insuffisants . Répéter demande ne fonctionnera pas, à moins que les qualifications aient changé, ce qui est très peu probable dans un court laps de temps.

introuvable : code d'état (404) indiquant que la ressource demandée n'est pas disponible. L'utilisateur/agent connu, mais le serveur ne révèle rien sur la ressource, fait comme si elle n'existe pas. Répéter ne marchera pas. C'est une utilisation spéciale de 404 (github le fait par exemple).

si l'authentification en tant qu'autre utilisateur permet l'accès à la ressource demandée, alors 401 non autorisé devrait être retourné. 403 Forbidden est principalement utilisé lorsque l'accès à la ressource est interdit à tout le monde ou limité à un réseau donné ou autorisé uniquement sur SSL, aussi longtemps que ce n'est pas lié à l'authentification.

De la RFC 7235 (Protocole de Transfert Hypertexte (HTTP/1.1): l'Authentification):

3.1. 401 non autorisé

le code de statut 401 (non autorisé) indique que la demande: pas été appliqué parce qu'il manque valide les informations d'authentification pour la ressource cible. Le serveur d'origine doit envoyer un Le champ D'en-tête WWW-Authenticate (Section 4.4) contient au moins un défi applicable à la ressource cible. si la requête inclus les justificatifs d'authentification, puis la réponse 401 indique que l'autorisation a été refusée pour ceux les informations d'identification . Le client peut répéter la demande avec un nouveau ou remplacer le champ d'en-tête D'autorisation (Section 4.1). Si les 401 réponse contient le même défi que la réponse précédente, et le l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors le mandataire utilisateur doit présenter la représentation ci-jointe au utilisateur car il contient généralement pertinentes pour le diagnostic.

Et voici de RFC 2616:

10.4.4 403 Interdit

Le serveur a compris la requête, mais refuse de la satisfaire.

L'autorisation n'aidera pas et la demande ne doit pas être répétée.

Si la méthode de requête N'était pas HEAD et que le serveur souhaite faire

public pourquoi la demande n'a pas été satisfaite, elle doit décrire la raison pour le refus de l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code de statut 404

(Pas Trouvé) peut être utilisé à la place.

Edit: RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): sémantique et contenu) change le sens de 403:

6.5.3. 403 Interdit 151910920"

le code de statut 403 (Interdit) indique que le serveur compris la requête, mais refuse de l'autoriser. Un serveur qui souhaite rendre public pourquoi la demande a été interdit peut décrivez cette raison dans la charge utile de réponse (le cas échéant).

si des justificatifs d'authentification ont été fournis dans la demande, le

serveur les juge insuffisantes pour accorder l'accès. Le client

Ne devrait pas automatiquement répéter la demande avec le même

références. Le client peut répéter la demande avec nouveau ou différent références. Toutefois, une requête peut être interdite pour des raisons

sans rapport avec les pouvoirs.

un serveur d'origine qui souhaite" Cacher "l'existence actuelle d'un

la ressource cible interdite peut répondre avec un code d'état de

404 (Non Trouvé).

ainsi, un 403 peut signifier n'importe quoi. Fournir de nouveaux titres de compétences pourrait aider... ou il ne pourrait pas.

c'est une question plus ancienne, mais une option qui n'a jamais vraiment été soulevée était de retourner un 404. Du point de vue de la sécurité, la réponse la plus élevée souffre d'une vulnérabilité potentielle de fuite d'information . Disons, par exemple, que la page Web sécurisée en question est une page d'administration du système, ou peut-être plus communément, est un enregistrement dans un système auquel l'utilisateur n'a pas accès. Idéalement, vous ne voudriez pas qu'un utilisateur malveillant sache qu'il y a une page / enregistrement il, et encore moins qu'ils n'y ont pas accès. Quand je construirai quelque chose comme ça, j'essaierai d'enregistrer les requêtes non autorisées dans un journal interne, mais je vous renvoie un 404.

OWASP a quelques plus d'informations sur la façon dont un attaquant pourrait utiliser ce type d'informations dans le cadre d'une attaque.

cette question a été posée il y a quelque temps, mais la pensée des gens va de l'avant.

Section 6.5.3 dans ce brouillon (rédigé par Fielding et Reschke) donne au code de statut 403 une signification légèrement différente de celle documentée dans RFC 2616 .

il reflète ce qui se passe dans les systèmes d'authentification et d'autorisation employés par un certain nombre de serveurs Web populaires et cadres.

j'ai souligné le peu que je pense est le plus saillant.

6.5.3. 403 Interdit

le code de statut 403 (Interdit) indique que le serveur a compris la requête mais refuse de l'autoriser. Un serveur qui souhaite rendre publique la raison pour laquelle la requête a été interdite peut décrire cette raison dans la charge utile de réponse (le cas échéant).

si les justificatifs d'authentification étaient fournis en la requête, le serveur considère comme insuffisante pour accorder l'accès. le client ne doit pas répéter la demande avec les mêmes justificatifs d'identité. Le client peut répéter la demande avec des justificatifs d'identité nouveaux ou différents. toutefois, une demande peut être interdite pour des raisons sans rapport avec les pouvoirs.

un serveur d'origine qui souhaite "Cacher" l'existence actuelle d'une ressource cible interdite peut à la place répondre par un code d'état 404 (non trouvé).

quelle que soit la convention que vous utilisez, l'important est de fournir une uniformité à travers votre site / API.

TL; DR

• 401: un refus lié à l'authentification
• 403: un refus qui N'a rien à voir avec l'authentification

Exemples Pratiques

si apache nécessite une authentification (via .htaccess ), et que vous appuyez sur Cancel , il répondra avec un 401 Authorization Required

si nginx trouve un fichier, mais n'a pas droits d'accès (utilisateur / groupe) pour le lire / y accéder, il répondra par 403 Forbidden

RFC (2616 Section 10)

401 non autorisé (10.4.2)

Sens 1: besoin d'authentifier

la requête nécessite une authentification de l'utilisateur. ...

Signification 2: authentification insuffisante

... Si la demande comprenait déjà des justificatifs d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces justificatifs. ...

403 Interdit (10.4.4)

Signification: sans rapport avec l'authentification

... Autorisation ne va pas aider ...

plus de détails:

• Le serveur a compris la requête, mais refuse de la satisfaire.

• elle doit décrire le motif du refus dans l'entité

• le code d'état 404 (Non Found) peut être utilisé à la place de

  (si le serveur veut garder cette information du client)

ils ne sont pas connectés ou n'appartiennent pas au groupe d'utilisateurs approprié

vous avez déclaré deux cas différents; chaque cas devrait avoir une réponse différente:

1. S'ils ne sont pas connectés du tout, vous devez retourner 401 non autorisé
2. S'ils sont connectés mais n'appartiennent pas au groupe d'utilisateurs approprié, vous devez retourner 403 Forbidden

je pense qu'il est important de considérer que, pour un navigateur, 401 initie un dialogue d'authentification pour l'utilisateur d'entrer de nouveaux justificatifs d'identité, tandis que 403 ne le fait pas. Les navigateurs pensent que, si un 401 est retourné, alors l'utilisateur devrait ré-authentifier. Ainsi, 401 signifie authentification non valide, tandis que 403 signifie absence de permission.

voici quelques cas, selon cette logique, où une erreur serait renvoyée de l'authentification ou de l'autorisation, avec des phrases importantes en caractères gras.

• Une ressource nécessite une authentification, mais aucune information d'identification ont été spécifié .

401 : le client doit préciser ses justificatifs d'identité.

• les justificatifs d'identité spécifiés sont dans un format non valide .

400 : ce n'est ni 401 ni 403, comme les erreurs de syntaxe doivent toujours renvoyer 400.

• les justificatifs d'identité spécifiés font référence à un utilisateur qui n'existe pas .

401 : le client doit préciser les justificatifs d'identité valides.

• les "credentials sont invalides mais spécifiez un utilisateur valide (ou ne spécifiez pas un utilisateur comme un utilisateur spécifié n'est pas nécessaire).

401 : encore une fois, le client doit préciser les justificatifs d'identité valides.

• le lettres de créance ont expiré .

401 : c'est pratiquement la même chose que d'avoir des justificatifs d'identité invalides en général, donc le client doit spécifier des justificatifs d'identité valides.

• les justificatifs d'identité spécifiés sont entièrement valides , mais ne suffisent pas 151970920 "le particulier ressource , bien qu'il soit possible que les justificatifs d'identité avec plus de permission pourraient.

• les justificatifs d'identité spécifiés sont entièrement valides, mais le "client" Particulier 151960920 est bloqué de les utiliser.

403 : si le client est bloqué, spécifier de nouvelles références ne fera rien.

C'est plus simple dans ma tête que n'importe où ici, donc:

401: vous avez besoin de HTTP basic auth pour voir cela.

403: vous ne pouvez pas voir cela, et HTTP basic auth ne vous aidera pas.

si l'Utilisateur a juste besoin de se connecter en utilisant le formulaire HTML standard de connexion de votre site, 401 ne serait pas approprié parce qu'il est spécifique à L'auth HTTP basic.

je ne recommandent pas l'utilisation de 403 à refuser l'accès à des choses comme /includes , parce qu'en ce qui concerne le web, ces ressources n'existent pas du tout et devraient donc 404.

il reste 403 comme"vous devez être connecté".

en d'autres termes, 403 signifie"cette ressource nécessite une forme d'auth autre que L'auth HTTP de base".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

étant donné les dernières RFC sur la question ( 7231 et 7235 ) , le cas d'utilisation semble très clair (italiques ajoutées):

• 401 est pour non authentifié ("manque d'authentification valide"); c.-à-d. " Je ne sais pas qui vous êtes, ou Je ne crois pas que vous êtes qui vous dites être."

401 non autorisé

le code de statut 401 (non autorisé) indique que la demande n'a pas 1519190920 " pouvoirs pour la ressource cible. Le serveur générant une réponse 401 doit envoyer un champ D'en-tête WWW-Authenticate (Section 4.1) contenant au moins un défi applicable à la ressource cible.

si la demande incluait des justificatifs d'authentification, alors le réponse indique que l'autorisation a été refusée pour ceux références. L'agent utilisateur peut répéter la requête avec un nouveau ou remplacer le champ d'en-tête D'autorisation (Section 4.2). Si les 401 réponse contient le même défi que la réponse précédente, et le l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors le mandataire utilisateur doit présenter la représentation ci-jointe au utilisateur car il contient généralement pertinentes pour le diagnostic.

• 403 signifie non autorisé ("refuse d'autoriser"); c.-à-d. " je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource."

403 Interdit

le code de statut 403 (Interdit) indique que le serveur a compris la demande mais refuse d'autoriser . Un serveur qui souhaite de rendre publique la raison pour laquelle la demande a été interdite peut décrire que raison dans la charge utile de réponse (le cas échéant).

si des justificatifs d'authentification étaient fournis dans la demande, le serveur les juge insuffisantes pour accorder l'accès. Client Ne devrait pas automatiquement répéter la demande avec le même références. Le client peut répéter la demande avec nouveau ou différent références. Toutefois, une requête peut être interdite pour des raisons sans rapport avec les pouvoirs.

Un serveur d'origine, qui se veut "cacher" de l'existence actuelle d'un la ressource cible interdite peut à la place répondre avec un code d'état de 404 (Non Trouvé).

dans le cas du 401 vs 403, cela a été répondu à plusieurs reprises. Il s'agit essentiellement d'un débat sur L'environnement de requête HTTP, et non d'un débat sur l'application.

il semble qu'il y ait une question sur la question de l'application "roll-your-own-login".

dans ce cas, le fait de ne pas être connecté n'est pas suffisant pour envoyer un 401 ou un 403, à moins que vous n'utilisiez HTTP Auth par rapport à une page de connexion (non liée à la définition de HTTP Auth). On dirait que vous cherchez peut-être un "201 Created", avec un écran roll-your-own-login présent (au lieu de la ressource demandée) pour l'accès à un fichier au niveau de l'application.

"je vous ai entendu, c'est ici, mais essayez plutôt ceci (vous n'êtes pas autorisés à le voir)"