Estoy escribiendo una pequeña aplicación que expone una API HTTP REST-ish simple. Estoy atascado tratando de decidir cómo señalar una falla debido a la falta de autorización.Error de autenticación de señalización en una API RESTful
La aplicación no tiene una API para la autenticación, sino que depende de la presencia de una cookie que contiene un token de sesión obtenido por el cliente a través de otro servicio. La aplicación verifica la sesión y usa la identidad obtenida a través del proceso de verificación para realizar la autorización específica de la aplicación. No hay forma de que un cliente se autentique directamente en esta aplicación.
Mi problema es que el código de estado HTTP obvio para rechazar solicitudes no autorizadas, "401 no autorizado", se especifica en términos del encabezado "WWW-Authenticate". Ver rfc2616 sec 10.4.2.
la respuesta debe incluir un campo de cabecera WWW-Authenticate (sección 14,47) que contiene un desafío aplicable al recurso solicitado.
No puedo creer que este sea un problema poco común. ¿Es común simplemente sobrecargar 401 para incluir usos más generales? ¿Qué pasa con los navegadores que muestran diálogos de autenticación/e (que por cierto no he visto en mis pruebas, por lo que tal vez no suceda con los POST)?
En pocas palabras: ¿está bien utilizar 401 en este contexto, o hay una solución mejor?
No es una API RESTful si está utilizando una cookie. Los servicios REST son apátridas por definición. –
Punto justo: Cambié mi descripción a REST-ish, en lugar de RESTful. ¿Cree que la respuesta es implementar correctamente la autenticación por solicitud o abandonar mi intento de RESTishness? – j0ni
Es difícil de decir, depende de su aplicación. El enfoque REST tiene algunas ventajas. Si quieres seguir usando la sesión del lado del servidor, devolvería 403 como dijo Tvanfosson. –