Code de statut http correct pour la ressource nécessitant une autorisation

Question

Il semble y avoir beaucoup de confusion sur le code de statut http de retour si l'utilisateur tente d'accéder à une page qui demande à l'utilisateur de se connecter.

Donc, fondamentalement, ce code d'état est envoyer quand je montre la page de connexion?

Je suis sûr que nous avons besoin d'utiliser un code d'état dans l' 4xx de la gamme.

Je ne parle pas de l'authentification HTTP, ici, de sorte que c'est au moins 1 code d'état, nous n'allons pas utiliser (401 Unauthorized).

Maintenant que devrions-nous utiliser? Les réponses (ici aussi, sur DONC) semblent varier:

Selon la réponse ici, nous devrions utiliser 403 Forbidden.

Mais dans la description du code d'état est:

L'autorisation ne sera pas l'aide et de la demande ne DOIT PAS être répété.

Bien que ne ressemble pas à celui de droite. Depuis l'autorisation de l'aide.

Donc permet de vérifier certaines autres réponses. La réponse ici même n'utilise pas l' 4xx gamme, mais utilise plutôt 302 Found

La description de l' 302 Found code d'état:

La ressource demandée réside temporairement dans une autre URI. Depuis la redirection peut être modifiée à l'occasion, le client DEVRAIT continuer à utiliser l'URI de Demande pour les demandes futures. Cette réponse n'est mis en cache si elle est indiquée par un Cache-Control ou l'Expiration de champ d'en-tête.

Je pense que n'est pas ce que je veux. Car ce n'est pas la ressource demandée, qui se trouve sous un autre URI. Mais plutôt une complètement différente de la ressource (page de connexion vs authentifié contenu de la page).

J'ai donc déplacé le long et de chercher une autre réponse étonnamment avec encore une autre solution.

Cette réponse suggère que nous choisissons 400 Bad Request.

La description de ce code d'état est:

La demande ne peut pas être comprise par le serveur en raison de la malformation de la syntaxe. Le client ne DOIT PAS répéter la requête sans modifications.

Je pense que le serveur a compris la requête, mais refuse juste de donner accès avant que l'utilisateur est authentifié.

Une autre réponse , dit 403 réponse est correcte, mais il se termine par:

Si c'est un site web où vous êtes en essayant de refuser l'accès basé sur un cookie de session [c'est ce que je fais], de 200 avec un organisme approprié pour indiquer que la session est nécessaire ou un 302 temporaire rediriger vers une page de connexion est souvent meilleur.

Donc, 403 "est correct, mais 200 ou 302 est LE MEILLEUR.

Hey! C'est ce que je suis à la recherche d': LA MEILLEURE solution. Mais elle ne devrait pas non plus être la même que celle qui est correcte? Et pourquoi serait-il le meilleur?

Merci à tous ceux qui ont fait cela loin dans cette question :)

Je sais que je ne devrais pas trop de soucis à ce sujet. Et je pense que c'est une question hypothétique (pas vraiment, mais utilisé en raison de manque d'un meilleur mot).

Mais cette question me hante depuis quelques temps maintenant.

Et si j'aurais été un manager (qui a juste pris quelques frais de sonner les mots comme ils le font toujours), j'aurais dit: mais, mais, mais, mais sous le signe du repos est important. :-)

Donc: qu'est - the right way™ de l'utilisation d'un code d'état dans la situation ci-dessus (le cas échéant)?

tl;dr

Est-ce le bon code de statut http de la réponse lorsqu'un utilisateur tente d'accéder à une page qui nécessite un nom d'utilisateur?

Answer 1

Si l'utilisateur n'a pas fourni toutes les informations d'identification et votre API exige d'eux, de retour d'un 401 - Unauthorized. Qui mettra au défi le client à faire. Il y a généralement peu de débat sur ce scénario particulier.

Si l'utilisateur a fourni des informations d'identification valides, mais ils sont insuffisants pour accéder à la ressource demandée (peut-être les informations d'identification ont été pour un freemium compte, mais la ressource demandée est seulement pour votre payé les utilisateurs), vous avez deux options étant donné le manque de rigueur de certains des HTTP définitions de code:

1. De retour 403 - Forbidden. C'est plus descriptif et est généralement comprise comme, "les informations d'identification fournies étaient valides, mais encore n'ont pas été suffisante pour accorder l'accès"
2. De retour 401 - Unauthorized. Si vous êtes paranoïaque à propos de la sécurité, vous pourriez ne pas vouloir donner de l'information supplémentaire pour le client comme l'a retourné dans (1) ci-dessus
3. Les retourner en 401 ou 403 , mais avec des informations utiles dans le corps de la réponse décrivant les raisons pour lesquelles l'accès est refusé. Encore une fois, cette information peut être plus que vous ne le souhaitez fournir au cas où il permet à des attaquants un peu.

Personnellement, j'ai toujours utilisé #1 pour le scénario, dans lequel les informations d'identification valides ont été adoptées, mais le compte auquel elles sont associées n'ont pas accès à la ressource demandée.

Answer 2

Vous vous demandez pour "le meilleur", "le droit chemin", et "le bon", à son tour, ce qui permet de répondre à cette question difficile car les critères ne sont pas nécessairement interchangeables et peuvent, en fait, les conflits, surtout lorsque la Détente est concerné.

La "meilleure" réponse dépend de votre application. Construisez-vous un bon Vieux Navigateur-Basé (POBB) web-application? Construisez-vous un client natif (ex. iOS ou Android) et de frapper d'un service sur le Web? Êtes-vous fait un usage intensif de l'AJAX ou du lecteur de la page web de mises à jour? Est-curl au client?

Supposons que vous êtes un bâtiment traditionnel de l'application web. Regardons comment Google fait-il (sortie haché par souci de concision):

$ curl -v http://gmail.com/
< HTTP/1.1 301 Moved Permanently
< Location: http://mail.google.com/mail/
< Content-Type: text/html; charset=UTF-8
< Content-Length: 225
< ...

Google nous ramène à la "vraie" URL pour GMail (à l'aide d'une redirection permanente).

$ curl -v http://mail.google.com/mail/
< HTTP/1.1 302 Moved Temporarily
< Location: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1&ltmpl=default&ltmplcache=2
< Content-Type: text/html; charset=UTF-8
< Content-Length: 352
< ...

Et puis, il nous redirige vers la page de connexion (à l'aide d'une redirection 302).

$ curl -v 'https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=http://mail.google.com/mail/&scc=1&ltmpl=default&ltmplcache=2'
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< ...

La page de connexion elle-même est livré avec le code d'état 200!

Pourquoi de cette façon?

À partir de l'expérience utilisateur en perspective, si un utilisateur accède à une page, ils ne peuvent pas afficher parce qu'ils ne sont pas authentifiés, vous voulez prendre l'utilisateur vers une page qui leur permet de corriger ce (via la connexion). Dans cet exemple, la page de connexion est seul, et qui est juste une autre page (c'est pourquoi 200 cas).

Vous pouvez jeter un 4XX page avec une explication et un lien vers la page de connexion. Qui pourrait, en effet, semblent plus Reposant. Mais c'est de pire expérience de l'utilisateur.

Ok, mais est-il un cas où quelque chose comme 403 sens? Absolument.

Mais d'abord, notez que 403 n'est pas bien définie dans la spécification. Afin de comprendre comment il doit être utilisé, vous avez besoin de regarder la façon dont il est mis en œuvre sur le terrain.

403 est couramment utilisé par les serveurs web, comme Apache et IIS, comme le code de statut pour les pages renvoyées lorsque le navigateur demande une liste de répertoires (URI se terminant par"/"), mais le serveur a des listes de répertoire désactivé. Dans ce cas, 403 est vraiment spécialisé 404, et il n'y en a pas beaucoup que vous pouvez faire pour l'utilisateur sauf laissez-lui/elle savoir ce qui n'allait pas.

Cependant, voici un exemple d'un site qui utilise la 403 à la fois le signal à l'utilisateur qu'il/elle n'a pas les privilèges suffisants et les mesures à prendre pour corriger la situation (voir la réponse complète pour plus de détails):

curl -v http://www.w3.org/Protocols/rfc2616/
< HTTP/1.1 403 Forbidden
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 1564
< ...

(En aparté, 403 est également visible sur le web, Api, à l'instar de l'API Twitter; ici, 403 signifie "La demande est entendu, mais il a été refusé. Accompagnement d'un message d'erreur s'expliquer pourquoi. Ce code est utilisé lorsque des demandes sont refusées en raison de la mise à jour des limites.")

Comme une amélioration, supposons, cependant, que vous ne voulez pas rediriger l'utilisateur vers une page de connexion, ou de forcer l'utilisateur à suivre un lien vers la page de connexion. Au lieu de cela, vous souhaitez afficher le formulaire de connexion sur la page que l'utilisateur est empêché de voir. Si elles ont réussi à s'authentifier, ils voient le contenu lorsque la page est actualisée; s'ils échouent, ils obtenir de nouveau le formulaire de connexion. Ils n'ont jamais naviguer vers une autre URL.

Dans ce cas, un code d'état de 403 fait beaucoup de sens, et est l'homologue de l'401 cas, avec la réserve que le navigateur n'affiche pas d'une boîte de dialogue demandant à l'utilisateur de s'authentifier -- le formulaire dans la page elle-même.

Cette approche de l'authentification n'est pas commun, mais il pourrait avoir un sens, et est à mon humble avis préférable à la pop-up-a-javascript-modal-à-journal-dans les solutions que les développeurs essaient de mettre en œuvre.

Il en revient à la question, voulez-vous de rediriger ou pas?

Complémentaires: pensées sur le code de statut 401...

Le code de statut 401 -- et associé de base/l'authentification digest -- a beaucoup de choses pour elle. Il est embrassé par la spécification HTTP, il est pris en charge par tous les principaux navigateurs, il n'est pas intrinsèquement de l'onu-Sommeil... Le problème est, à partir d'une perspective de l'expérience utilisateur, c'est très très peu attrayant. Il y a l'onu-à styliser, cryptique de dialogue pop-up, l'absence d'une solution élégante pour la déconnexion, etc. Si vous (ou vos partenaires/clients) peuvent vivre avec ces questions (un grand si), alors qu'il pourrait être considéré comme la "bonne" solution.

Answer 3

D'accord. RESTE est juste un style, pas un protocole strict. De nombreux services web publics s'écarter de ce style. Vous pouvez construire votre service pour retourner tout ce que vous voulez. Juste assurez-vous que vos clients savent comment ce que les codes de retour à attendre.

Personnellement, j'ai toujours utilisé 401 (non autorisé) pour indiquer à un utilisateur non authentifié a demandé une ressource qui nécessite une authentification. J'ai alors besoin de l'application client guide de l'utilisateur pour la connexion.

J'utilise 400 (bad request) en réponse à une tentative d'ouverture de session avec les informations d'identification non valides.

HTTP 302 (déplacé) semble plus appropriée pour les applications web où le client est un navigateur. En général, les navigateurs suivent la ré-adresse directe dans la réponse. Cela peut être utile pour guider l'utilisateur vers une page d'ouverture de session.

Answer 4

Votre "TL;DR" ne correspond pas à la "TL" version.

La bonne réponse pour la demande de l'une des ressources que vous avez besoin d'autorisation à demander, est-401.

302 n'est pas la bonne réponse, parce que, en fait, la ressource n'est pas disponible ailleurs. L'URL d'origine est correct, le client n'a tout simplement pas les droits. Si vous suivez la redirection, vous n'avez pas réellement obtenir ce que vous cherchez. Vous obtenez chuté dans certains ad hoc de flux de travail qui n'a rien à faire avec la ressource.

403 est incorrect. 403 est le "vous ne pouvez pas y arriver d'ici" erreur. Vous simplement ne pouvez pas voir cela, je ne m'inquiète pas qui vous êtes. Certains diront 403 et 404 sont similaires. La différence est simplement avec 403, le serveur est en train de dire "oui, je l'ai, mais vous ne pouvez pas", alors que les 404 dit "je ne sais rien à propos de quoi vous parlez." Sécurité wonks dirais que la 404 est "plus sûr". Pourquoi dites-leur quelque chose qu'ils n'ont pas besoin de savoir.

Le problème que vous rencontrez n'a rien à voir avec le REPOS ou HTTP. Votre problème est d'essayer de mettre en place des dynamiques de la relation entre le client et le serveur, qui se manifeste en fin de compte via un cookie. L'ensemble de la ressource -> 302 -> page de Connexion est tout sur l'expérience utilisateur en utilisant le hack qui est connue comme le Navigateur Web, qui se trouve être à la fois, en stock forme, d'un mauvais client HTTP et un moche RESTE des participants.

HTTP est un mécanisme d'autorisation. L'en-tête d'Autorisation. L'expérience utilisateur autour d'elle, dans un générique du navigateur, est terrible. Afin que personne ne l'utilise.

Donc, il n'y a pas de bonne réponse HTTP (il y a bien, 401, mais ne pas/ne peut pas l'utiliser). Il n'y a pas de bon REPOS réponse, comme le RESTE repose généralement sur le protocole HTTP (dans ce cas, mais nous avons abordé déjà).

Donc. 302 -> 200 pour la page de connexion est tout ce qu'elle a écrit. C'est ce que vous obtenez. Si vous n'utilisez pas le navigateur, ou a tout fait via XHR ou de quelque autre client personnalisé, ce ne serait pas un problème. Vous devriez juste l'Autorisation d'utilisation de l'en-tête, suivez le protocole HTTP, et à bénéficier d'un régime comme de type DIGEST ou ce qu'AWS utilise, et à faire. Ensuite, vous pouvez utiliser les normes appropriées pour répondre à de telles questions.