Code HTTP à utiliser dans “Non Authentifié” et “Non autorisé” cas?

J'ai lu que "401 Unauthorized" code doit être utilisé lorsqu'un utilisateur:

  1. N'est pas connecté, mais la connexion est requis ("non authentifié");
  2. Est connecté, mais son profil ne permet pas de voir que l'url ("non autorisé");

Conformément à la RFC, dans les deux cas, le serveur doit retourner 401 code.
Mais j'ai besoin de différencier ensuite dans mes requêtes ajax.

Quelqu'un a une astuce pour résoudre ce problème?

Remarque: je ne veux pas utiliser 403 Forbidden code, parce que dans 403 "Authorization will not help", conformément à la RFC.

InformationsquelleAutor Topera | 2011-05-24
  1. 2

    Vous devriez passer un en-tête personnalisé en plus du code d'état pour l'application à des besoins spécifiques.

    Je crois que la pratique actuelle est de préface en-têtes personnalisés avec X-

    Mise À Jour, Août 2012:

    De la RFC 3864 posté dans les commentaires (en date de septembre 2004):

    Dans certains cas (notamment HTTP [24]), l'en-tête de la syntaxe et l'utilisation est
    redéfini pour l'application spécifique.
    [...]
    Dans certains cas, le même nom de champ peut être spécifié différemment (par
    différents documents) pour une utilisation avec les différents protocoles d'application.
    [...]
    Nous devons nous adapter à l'application des champs spécifiques, tout en souhaitant
    reconnaître et promouvoir l' (le cas échéant) de points communs à d'autres champs
    à travers de multiples applications.

    Plus récente RFC (Six mille six cent quarante huit, datée de juin 2012), ils ont expressément adresse X- en-têtes.

    Dénonçait le "X" de la convention pour les nouveaux paramètres définis dans
    les protocoles d'application, y compris de nouveaux paramètres pour établi
    les protocoles. [...] Ne recommande pas à l'encontre de la pratique privée,
    local, préliminaire, de l'expérimentation ou de mise en œuvre spécifiques
    paramètres, seul contre l'utilisation de "X" et d'autres constructions similaires dans le
    les noms de ces paramètres.

    Important à noter est que, bien que X- est spécifiquement noté, ils ne sont toujours implicitement cautionner des en-têtes personnalisés comme un moyen de transfert de l'information. Une application spécifique préfixe (MyApp-) pourrait être plus approprié pour éviter la collision avec les autres en-têtes.

    Voir aussi: Est-il sécuritaire d'utiliser "X" en-tête dans une réponse HTTP à partir d'un il ya quelques années.

    • "X" n'est pas spécial dans les champs d'en-tête HTTP. Voir la RFC 3864.
    • Attendez, avez-vous sérieusement downvote moi pour cela? Les "Standard" sont pas, par définition, depuis, a vous de lire la définition, vous verriez que la définition spécifique à l'application en-têtes est le concepteur de l'application: il n'y a pas de norme. C'est un "standard" parce que c'est la façon dont la plupart des gens le faire, et il a été accepté que X- dénote généralement un en-tête personnalisé que le navigateur peut ignorer pour une utilisation régulière.
    • Juste parce que c'est "pratique courante" ne signifie pas que c'est la bonne chose à faire. Il existe de bien meilleures façons de se qualifier précisément de ce qu'un code d'état HTTP moyens. par exemple rendre un corps avec des détails.
    • Un en-tête personnalisé n'est significatif que si vous aussi ont un navigateur personnalisé qui va l'interpréter. Sinon, tout va ignorer votre en-tête personnalisé et il n'aura aucun effet.
    • L'hypothèse serait que l'en-tête personnalisé est interprétée par une application côté serveur ou une application côté client, à la fois de ce qui serait un précurseur de même en utilisant les en-têtes personnalisés. Si vous essayez de provoquer le navigateur automatiquement faire quelque chose, alors que vous auriez à utiliser l'un des pré-défini codes de réponse, ou de l'utilisation d'un navigateur personnalisé comme vous le suggérez.
    InformationsquelleAutor rockerest
  2. 42

    Sauf si vous avez l'intention d'utiliser l'authentification HTTP, la bonne réponse est 403 ("Interdit").

    Un code de réponse de 401 déclenche le navigateur pour afficher un mot de passe de la boîte de dialogue, puis la soumettre de nouveau la même demande à un WWW-Authenticate - tête avec les données de mot de passe que l'utilisateur a fourni. Ce n'est probablement pas le comportement que vous souhaitez.

    N'obtenez pas trop accroché sur les explications dans la Rfc -- ce que vous avez vraiment besoin de prêter attention à l'navigateur et moteur de recherche des effets secondaires des différents codes de réponse.

    Comme pour le "Authorization will not help" peu, dans ce cas, c'est exact, puisque l'utilisation de HTTP autorisation (ce qui signifie plus précisément le WWW-Authenticate en-tête), en fait, ne va pas aider.

    Une réponse 403 indique au navigateur que l'utilisateur n'est pas autorisé à en faire la demande, et le navigateur doit pas tenter de recueillir des données d'authentification et de soumettre à nouveau la demande. C'est exactement la réponse que vous êtes après.

    • C'est la réponse correcte.
    InformationsquelleAutor tylerl
  3. 9

    Je crois 403 est la bonne. Nous pourrions avoir à régler la langue dans le cahier des charges pour que ce soit clair.

    • Dans l'esprit de votre mesquinerie, voici le RFC montrant que votre réponse est complètement et clairement mauvais, de par leur conception. C'est la section 10.4.4
    • rockerest; tout d'abord la RFC 2068 a été rendu obsolète par la RFC 2616 il y a longtemps. Deuxièmement, j' crois pour utiliser la 403 est le bon choix (voir tylerl de réponse), et si le texte de la spécification suggère le contraire, nous devrions envisager de le changer. Oui, nous le pouvons.
    • (la question est maintenant suivie dans le HTTPbis Groupe de Travail en tant que trac.tools.ietf.org/wg/httpbis/trac/ticket/294)
    • C'est une excellente nouvelle. Cette ambiguïté dans la spec a été déroutant pour moi un moment.
    • trac.tools.ietf.org/wg/httpbis/trac/changeset/1301
    InformationsquelleAutor Julian Reschke
  4. 2

    IIS différencie ces cas avec des sous-codes d'état (référence):

    • 401 = Utilisateur n'est pas connecté, mais la connexion est nécessaire
    • 401.1 = L'utilisateur a essayé de se connecter, mais leurs informations ne sont pas valides.
    • 401.3 = les références de L'utilisateur sont valides, mais l'utilisateur n'est pas autorisé à voir la ressource.
    • Qui, autant que je me souvienne, ne sont pas valides par la HTTP spec: "la Ligne d'État = HTTP-Version SP Status-Code SP Raison-Phrase CRLF [...] L'État-Code l'élément est un 3 chiffres integer code de résultat" (l'emphase est mienne)
    • Je n'ai pas testé mais je suppose qu'IIS n'envoie 3 chiffres des codes standard dans la ligne d'état. Le sous-état est envoyé dans la 'raison' expression, certains propriétaires en-tête ou dans le corps de la réponse seulement, si elle est envoyée à tous.
    • Ces différenciées indicateurs d'état sont utilisées en interne par le serveur IIS pour afficher une autre page d'erreur en fonction de la raison pour montrer l'erreur.
    InformationsquelleAutor David