2012-02-09 14 views
22

Un servicio de autenticación permite que las cuentas de usuario se deshabiliten (una especie de eliminación de software).HTTP 401 no autorizado o 403 prohibido para un usuario "deshabilitado"?

Si el servidor recibe una solicitud de autenticación para un usuario deshabilitado que de otro modo sería válida, ¿debería el servidor devolver 401 o 403? Con cualquiera de los códigos de estado, devolvería un mensaje que indica que la cuenta se ha deshabilitado.

Para tener una referencia rápida, citas relevantes de HTTP/1.1 spec (el énfasis es mío):

401 no autorizadas

La solicitud requiere autenticación de usuario. La respuesta DEBE incluir un campo de encabezado WWW-Authenticate (sección 14.47) que contenga un desafío aplicable al recurso solicitado. El cliente PUEDE repetir la solicitud con un campo de encabezado Autorización adecuado (sección 14.8). Si la solicitud ya está incluida Credenciales de autorización, entonces la respuesta 401 indica que se ha rechazado la autorización para las credenciales . Si la respuesta 401 contiene el mismo desafío que la respuesta antes , y el agente de usuario ya ha intentado autenticación al menos una vez, entonces el usuario se debe presentar la entidad que se le dio en la respuesta, ya que la entidad podría incluir información de diagnóstico relevante. La autenticación de acceso HTTP se explica en "Autenticación HTTP: Acceso básico y abreviado Autenticación" [43].

403 Forbidden

El servidor entendido la petición, pero se niega a cumplirlo. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no fue HEAD y el servidor desea hacer público por qué la solicitud no se ha cumplido, DEBE describir el motivo para la denegación en la entidad. Si el servidor no desea poner esta información a disposición del cliente, en su lugar se puede usar el código de estado 404 (No encontrado).

+0

Pregunta similar aquí (podría ayudar un poco): http://stackoverflow.com/questions/8389253/correct-http-status-code-for-resource-which-requires-authorization/ –

Respuesta

30

Basado en an email escrito por Roy T. Fielding, aparentemente hay a bug en la especificación HTTP actual.

La forma en la especificación está destinado para ser leído, es el siguiente (utilizando citas de correo electrónico anterior):

401 "autenticado":

no se puede hacer esto porque no se ha autenticado

403 "no autorizado":

agente de usuario enviado credenciales válidas, pero no tiene acceso

Así, en el caso de un usuario con discapacidad, 403 es la respuesta correcta (y 404 es también una opción).

1

técnicamente ambos son correctos, realmente se reduce a la cantidad que desea revelar.

al devolver un 401 dice a la persona que llama que la cuenta no es válida, lo cual es correcto, pero si su API se va a volver a llamar para registrar un usuario con las mismas credenciales, esa llamada también fallará. que puede no ser de mucha utilidad para la persona que llama.

por lo tanto, realmente depende de cómo se usará su API y de quién/qué es el público objetivo.

9

Tengo dos respuestas diferentes para qué devolver en este caso.

Opción semántica - 401 No autorizado. En este caso, su cliente ha proporcionado credenciales, y la solicitud ha sido rechazada según las credenciales específicas. Si el cliente intentara de nuevo con un conjunto diferente de credenciales, o si la cuenta se volviera a habilitar en el futuro, la misma solicitud podría tener éxito.

Opción de seguridad - 404 No encontrado. Muchos servicios simplemente devolverán un 404 por cualquier falla, a fin de evitar la filtración de información. Github viene a mi mente de inmediato.

De General API Information, en documentos de desarrolladores de GitHub:

Las solicitudes no autenticadas volverán 404 para evitar cualquier tipo de fuga de información privada .

Para algo que estaba implementando como un servicio público, probablemente utilizaría 404 para evitar dar pistas a un atacante sobre sus intentos de credenciales. Si fuera solo para consumo interno o en pruebas, probablemente devolvería 401.

+0

+1, especialmente para hacer el caso de 404, pero creo que la especificación de HTTP está rota en función de la discusión y error de W3 que encontré. – Dolph

Cuestiones relacionadas