Corriger le code d'état HTTP, lorsque la ressource est disponible, mais pas accessible en raison des autorisations

Je fais construire une bonne protocole de Covoiturage Dynamique des applications, pour mon Ordinateur Sciences de la thèse.

Dans le Protocole j'ai aussi officiellement spécifier le code de statut HTTP pour chaque opération. J'ai eu cette "protection" problème. Supposons que le texte suivant:

GET /api/persons/angela/location

Récupère la position actuelle de l'utilisateur "angela".
Il est évident que tout le monde devrait être en mesure d'obtenir un résultat. Seule angela lui-même et un éventuel pilote qui va chercher sa devrait être en mesure de le savoir.

Je ne peux pas décider de renvoyer une 404 not Found ou un 401 Interdit ici.

Un indice? Quelle serait la meilleure et pourquoi?

  • Une erreur 404 est complètement incorrect ici car il indique que l'enregistrement n'existe pas du tout.
InformationsquelleAutor dgraziotin | 2010-08-23
  1. 19

    Selon Wikipédia (et La RFC 2616), 401 code est utilisé lorsqu'une page existe mais nécessite une authentification; 403 est une page où l'authentification ne changera rien. (Dans la nature, 403 signifie généralement les autorisations d'accès sont quelque chose de mal, alors qu'un 401 invite l'utilisateur à spécifier un nom d'utilisateur/mot de passe). 404 est pour le cas où le document n'existe tout simplement pas.

    Dans votre cas, il semble que 401 est la plus appropriée de code, car il est un moyen d'authentifier les utilisateurs qui ont accès à la page.

    • Bon! Tout à fait l'ensemble des opérations de protocole besoin d'authentifications. J'ai des cas dans lesquels les ressources sont disponibles, mais ne peut pas être récupéré, parce que les droits de l'utilisateur et aussi des cas où les ressources ne sont pas disponibles parce que l'ont été précédemment supprimé. Dans les deux cas, en vertu de authentifié opérations. Iriez-vous pour un 401 dans le premier cas et une 404 pour le deuxième cas? Donc: la ressource existe, mais vous ne pouvez pas y accéder -> 401 ressource n'existe pas -> 404
    • Oui, si une ressource a été supprimée, une erreur 404 est appropriée si une tentative est par la suite rendu à y accéder.
    • Bonne réponse, mais je préfère "selon Wikipédia" pour dire "selon la RFC 2616" tools.ietf.org/html/rfc2616#section-10.4.2 😉
    • Mais, en donnant la réponse 401 expose le fait que le fichier existe réellement.
    InformationsquelleAutor Phil
  2. 0

    Certainement PAS 404. 404 est tout simplement Pas Trouvé.

    401 accès est refusé.

    403 est interdit.

    Je voudrais aller avec 401

    • 401 est pas accès refusé. Il n'est "pas connecté et mot de passe requis".
    • Selon la RFC 2616 (tools.ietf.org/html/rfc2616#section-10.4.2), "Si la demande déjà inclus Autorisation des informations d'identification, puis la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification." Donc 401 est, en fait, l'accès est refusé.
    InformationsquelleAutor DmitryK
  3. 0

    Pour moi, je vais utiliser 400 Bad request.

    Parce que ma candidature ne sera pas aller unaccessable ressources par programme.

    Filtrage de l'autorisation de l'utilisateur et de cacher unaccessable ressources est une bonne expérience utilisateur, à mon avis.
    Si mon serveur eu unaccessable demande ce qui signifie que certaines personne essaie de faire quelque chose.

    C'est pourquoi j'ai choisi de 400 Bad request dans mes applications.

    • Je suis en désaccord. répondre avec un 400 Bad Request pour les demandes valides est une fracture de l'API. 400 Bad Request signifie que quelque chose est incorrect avec la demande. Toute personne utilisant votre API pense que la demande est mal, alors qu'en réalité, la demande est à droite, c'est littéralement ce que 401 et 403 sont pour. Cela rend les choses plus facile à déboguer.
    • Comme je l'ai dit les utilisateurs normaux ne jamais demander unaccessable ressources. Si mon serveur eu unaccessable demande ce qui signifie que certaines sournois personne qui tente de pirater unaccessable ressources. Aussi je ne pourrai jamais répondre le code d'erreur pour les demandes valides.
    • Vous devriez ne jamais faire des hypothèses sur ce que les utilisateurs normaux et ne fait pas. L'authentification n'est pas nécessairement une partie de la demande. Si vous êtes inquiet au sujet de sournois gens, la bonne solution n'est pas intentionnellement briser le HTTP (la sécurité par l'obscurité). La bonne solution est de mettre en place un pare-feu avant de votre API, de sorte que le sournois gens ne peuvent même pas la sonde de votre API en premier lieu.
    • Je n'ai jamais rien dit à propos de l'Authentification. Il ya beaucoup de différents ministères et de nombreux utilisateurs différents rôle dans mon application. Parce que mon client est une très grosse société. Dans mon application lots de données privées ici. Parce que chaque utilisateur est thread pour moi. Qui sait leur ordinateur piraté ou pas... En application front-end n'est jamais accès unaccessable ressources par programme. Donc, à côté serveur, je vais valider chaque demande par l'utilisateur, assurez-vous qu'il est valide la demande. Si ce n'est pas s'arrêter et répondre à 400.
    InformationsquelleAutor jeefo
  4. -1

    Si l'autorisation informations d'identification sont fournies dans la demande et le demandeur n'a pas les permissions pour accéder à cette ressource, alors vous devriez retourner 403.

    Si aucune autorisation n'informations d'identification sont fournies dans la requête, alors vous devez retourner 401.

    • Si l'autorisation informations d'identification sont fournies dans la demande et le demandeur n'a pas les permissions pour accéder à cette ressource, alors vous devriez retourner 401 pas un 403. La RFC 2616 explicitement dit que pour un 403, "l'Autorisation ne sera pas l'aide et de la demande ne DOIT PAS être répété" (tools.ietf.org/html/rfc2616#section-10.4.4). Donc si il y a des informations d'identification valides que donnerait la permission d'accéder à la ressource, de ne pas renvoyer une 403.
    • Vous avez absolument raison. Ma réponse est fausse. Hmm, vous apprenez quelque chose de nouveau chaque jour.
    • Pas de soucis. Comment avoir un coup de couteau à mon spin off de la question stackoverflow.com/q/4038981/445073 🙂
    InformationsquelleAutor Darrel Miller