php - ejemplos - ¿Qué código de estado http se supone que se utilizará para decirle al cliente que la sesión ha expirado?
etiquetas meta (9)
¿Qué pasa con 419? No es estándar, pero la descripción en Wikipedia parece encajar:
419 Tiempo de espera de autenticación
No forma parte del estándar HTTP, 419 Authentication Timeout denota que la autenticación previamente válida ha expirado. Se usa como una alternativa al 401 no autorizado para diferenciar a los clientes autenticados de otra manera a los que se les niega el acceso a recursos específicos del servidor.
En una página web, usa el administrador de conexión YUI / fuente de datos para enviar solicitudes AJAX al servidor, si la sesión (que contiene información sobre si el usuario ha sido autenticado) ya ha agotado el tiempo de espera, esas respuestas ajax solo pueden ser verificadas por autenticado los usuarios deben devolver un código de estado http, diciéndole al cliente que la sesión ya se ha agotado, luego el cliente simplemente lo redirige a la página de inicio de sesión o le pregunta si desea extender la sesión.
Mi pregunta es que, en esta situación, ¿qué código de estado http es el más apropiado para decirle al cliente que la sesión ha excedido el tiempo de espera?
Código 408. "Tiempo de espera de solicitud", parece perfecto - RFC 2616 explica que significa
El cliente no produjo una solicitud dentro del tiempo que el servidor estaba preparado para esperar.
es decir, exactamente un "tiempo muerto", ¡justo como lo requiere!
Creo que el código apropiado será 403 / Prohibido. No hay ninguno que esté directamente relacionado con las sesiones.
La verdad es que no hay un código de estado HTTP estándar para un tiempo de espera de sesión. Las sesiones se implementan en la capa de aplicación, no en la capa de transporte HTTP.
Hay un código de estado personalizado que Microsoft ha estado usando para el tiempo de espera de la sesión: 599, o simplemente crea su propio código de estado en el rango 5xx.
De la Wiki de códigos de estado:
599 Error de tiempo de espera de conexión de red (Desconocido) Este código de estado no se especifica en ningún RFC, pero lo utilizan los proxies HTTP de Microsoft Corp. para indicar un tiempo de espera de conexión de red detrás del proxy a un cliente que se encuentra frente al proxy.
Utilizo el código de estado personalizado 599 para un tiempo de espera de sesión y luego lo compruebo en la respuesta AJAX.
Lo mejor que puedo sugerir es un código de estado HTTP 401 con un encabezado WWW-Authenticate.
El problema con 403 solicitudes es el RFC 2616 que dice "La autorización no ayudará y la solicitud NO DEBE repetirse". (es decir, no importa si está autenticado o no, nunca tendrá acceso a ese recurso).
El problema con 401 solicitudes es que indica que "DEBE incluir un campo de encabezado WWW-Authenticate". Como alguien ha notado que no parece estar en violación de la especificación para usar un valor personalizado en un encabezado de WWW-Authenticate.
No veo ninguna razón en RFC 2617 por la cual un estado de HTTP 401 combinado con un encabezado WWW-Authenticate personalizado como este no estaría bien:
WWW-Authenticate: MyAuthScheme realm="http://example.com"
La especificación de oAuth en realidad parece hacer justamente esto, ya que lo recomiendan (aunque para mí tienen una extraña interpretación del RFC):
WWW-Authenticate: OAuth realm="http://server.example.com/"
Esto no parece SANCIONADO específicamente por el RFC, pero en realidad no puedo ver que esté prohibido (no parece entrar en conflicto con ninguna condición DEBE O NO DEBE, DEBERÍA o NO DEBE).
Ojalá hubiera un código de estado HTTP más específico para los tiempos de espera y para cosas como los tokens CSRF que no son válidos, así que esto era más claro.
Para solicitudes que no son Ajax, utilizo un redireccionamiento 302.
Para solicitudes Ajax, uso 200 para errores conocidos . De esa forma puedo aprovechar el objeto de datos. Encuentro que es más fácil trabajar con el objeto de datos que con el análisis de jqXHR para obtener información. Y luego no tengo que preocuparme por qué código de estado HTTP trataré de redirigir para mi situación.
jQuery Ejemplo:
$.ajax({
//send data to server
})
.done(function(data, textStatus, jqXHR) {
if (data.success) {
//then process return data
}
else {
//get error type or message from data object
//could use custom error codes
}
})
.fail(function(jqXHR, textStatus, errorThrown) {
//handle unknown errors
});
Según el enlace de Wikipedia de Http Status Codes proporcionado anteriormente por Bobo:
440 Login Timeout (Microsoft)
A Microsoft extension. Indicates that your session has expired.
Técnicamente, la respuesta aceptada es la correcta: si ya sabe con certeza que va a estar fallando la solicitud, y está preguntando qué código de falla devolver, entonces HTTP 401 "No autorizado (no autenticado)" es el apropiado, por lo que como para solicitar la reautenticación.
Pero ante todo, pregúntese: ¿ debería suspender la solicitud?
Tenga en cuenta que el usuario puede simplemente visitar una página pública de su sitio web, en cuyo caso los va a pegar en la cara con un "¡No autorizado!" mensaje, y les exige volver a autenticarse, para ver una página que normalmente podrían ver sin autenticación. Eso no es cool.
Mi consejo es ignorar el hecho de que el token de sesión es desconocido, y simplemente proceder a generar un nuevo token de sesión y crear una nueva sesión para él. El estado inicial de la sesión, por supuesto, será "aún no autenticado", por lo que si el usuario intenta acceder a una página no pública, la página se asegurará de que reciba un HTTP 401 "No autorizado (no autenticado) "y debe autenticarse. Pero si el usuario aterriza en una página pública, no notará nada diferente.
Yo recomendaría un HTTP 401.
Mientras que un 403 básicamente dice: "No está permitido, vete y no vuelves", un 401 dice: "No sabemos si estás permitido o no porque no trajiste tu identificación. Ir obténgalo y vuelva a intentarlo ".
Compare las definiciones de Wikipedia :
HTTP 403 : la solicitud era legal, pero el servidor se niega a responderla.
HTTP 401 : similar a 403 Prohibido, pero específicamente para uso cuando la autenticación es posible pero ha fallado o aún no se ha proporcionado.