Corregir el código de estado HTTP cuando el recurso está disponible pero no es accesible debido a los permisos

Estoy construyendo un protocolo RESTful para aplicaciones de Carpooling Dinámico, para mi tesis de Informática.Corregir el código de estado HTTP cuando el recurso está disponible pero no es accesible debido a los permisos

En el Protocolo, también debo especificar formalmente el código de estado HTTP para cada operación. Tengo este problema "relacionado con la privacidad". Supongamos que el siguiente:

GET /api/persons/angela/location

Recupera la posición actual del usuario "angela". Es obvio que no todo el mundo debería poder obtener un resultado. Solo Angela y un posible conductor que la va a recoger deberían saberlo.

No puedo decidir si me devuelve un 404 No Encontrado o un 401 Prohibido aquí.

¿Alguna pista? ¿Cuál sería el mejor y por qué?

Fuente

2010-08-23 dgraziotin

A 404 es completamente incorrecto aquí ya que indica que el registro no existe en absoluto. – You

De acuerdo con Wikipedia (y RFC 2616), se usa un código 401 cuando existe una página pero requiere autenticación; 403 es para una página donde la autenticación no cambiará nada. (En la naturaleza, 403 generalmente significa que los permisos en algo son incorrectos, mientras que un 401 solicitará al usuario un nombre de usuario/contraseña). 404 es para donde el documento simplemente no existe.

En su caso, parece que 401 es el código más apropiado, ya que hay alguna manera de autenticar a los usuarios que SI tienen acceso a la página.

Fuente

2010-08-23 12:30:22 Phil

¡Bueno! Todas las operaciones de protocolo requieren autenticaciones. Tengo casos en los que los recursos están disponibles pero no se pueden recuperar debido a los derechos de los usuarios y también a los casos en los que los recursos no están disponibles porque se eliminaron previamente. Ambos casos están bajo operaciones autenticadas. ¿Iría por un 401 en el primer caso y un 404 por el segundo caso? Por lo tanto: existe recurso pero no puede acceder a él -> 401 recurso no existe -> 404 – dgraziotin

Sí, si se eliminó un recurso, es apropiado un 404 si posteriormente se intenta acceder a él. – Phil

Buena respuesta, pero preferiría "según Wikipedia" decir "según RFC 2616" http://tools.ietf.org/html/rfc2616#section-10.4.2;) – Day

Definitivamente NO 404. 404 simplemente no se encuentra.
401 es acceso denegado.
403 está prohibido.

Me gustaría ir con 401

Fuente

2010-08-23 12:33:03 DmitryK

401 es * no * acceso negadoNo está "conectado y se requiere iniciar sesión". –

@EricStein De acuerdo con RFC 2616 (http://tools.ietf.org/html/rfc2616#section-10.4.2), "Si la solicitud ya incluía credenciales de autorización, entonces la respuesta 401 indica que la autorización ha sido rechazada para esas credenciales ". Entonces 401 es de hecho acceso denegado. –

-1

Si las credenciales de autorización están dentro de la solicitud y el solicitante no tiene permisos para acceder a este recurso, entonces debería regresar 403.

Si no hay credenciales de autorización se proporcionan en el solicitar entonces debe devolver 401.

Fuente

2010-08-23 12:51:53

Si se proporcionan credenciales de autorización en la solicitud y el solicitante no tiene permisos para acceder a este recurso, debe devolver 401 no a 403. RFC 2616 dice explícitamente que para un 403, "La autorización no ayudará y la solicitud NO DEBE repetirse". "(http://tools.ietf.org/html/rfc2616#section-10.4.4). Entonces, si hay credenciales válidas que darían permiso para acceder al recurso, no devuelva un 403. – Day

@Day Usted tiene toda la razón. Mi respuesta es incorrecta Hmm, aprendes algo nuevo todos los días. –

Sin preocupaciones. ¿Qué tal tener una puñalada en mi pregunta de spin off http://stackoverflow.com/q/4038981/445073 :) – Day

Para mí voy a utilizar la solicitud 400 Bad.
Porque mi aplicación no irá a recursos inaccesibles en forma programática.
En mi opinión, filtrar el permiso de los usuarios y ocultar los recursos no ejecutables es una buena experiencia para el usuario. Si mi servidor tiene una solicitud inasequible, lo que significa que una persona intenta hacer algo.
Es por eso que elijo 400 - Solicitud incorrecta en mis aplicaciones.

Fuente

2016-09-11 02:24:05 jeefo

No estoy de acuerdo. responder con 400 Bad Request para solicitudes válidas es una API rota. 400 Bad Request significa que algo está mal con la solicitud. Cualquiera que use su API pensará que la solicitud es incorrecta, cuando en realidad, la solicitud es correcta, esto es literalmente para lo que 401 y 403 son. Hace las cosas más fáciles de depurar. –

Como dije, los usuarios normales nunca solicitan recursos no accesibles. Si mi servidor tiene una solicitud inasequible, lo que significa que una persona astuta intenta piratear recursos que no se pueden ejecutar. Además, nunca responderé el código de error para solicitudes válidas. – jeefo

En general, nunca debe hacer suposiciones sobre lo que los usuarios normales harán y lo que no harán. La autenticación no es necesariamente parte de la solicitud. Si te preocupa la gente astuta, la solución correcta no es romper intencionalmente el HTTP (seguridad por oscuridad). La solución correcta es instalar un firewall frente a su API, de modo que las personas engañosas ni siquiera puedan sondear su API en primer lugar. –

Corregir el código de estado HTTP cuando el recurso está disponible pero no es accesible debido a los permisos

Respuesta

Cuestiones relacionadas