Cerrar sesión: GET o POST?

Esta pregunta no trata sobre cuándo usar GET o POST en general; se trata de cuál es la recomendada para manejar el cierre de sesión de una aplicación web. He encontrado mucha información sobre las diferencias entre GET y POST en el sentido general, pero no encontré una respuesta definitiva para este escenario en particular.

Como pragmático, me inclino a utilizar GET, porque implementarlo es mucho más simple que POST; simplemente suelta un enlace simple y listo. Este parece ser el caso con la gran mayoría de sitios web en los que puedo pensar, al menos desde lo más alto de mi cabeza. Incluso Stack Overflow maneja el cierre de sesión con GET.

Lo que me hace dudar es el argumento (aunque antiguo) de que algunos aceleradores / proxies web precalen páginas yendo y recuperando todos los enlaces que encuentran en la página, para que el usuario obtenga una respuesta más rápida cuando hace clic en ellos. No estoy seguro de si esto todavía se aplica, pero si este fuera el caso, en teoría un usuario con uno de estos aceleradores sería expulsado de la aplicación tan pronto como inicie sesión, porque su acelerador encontraría y recuperaría el cierre de sesión. enlace incluso si ella nunca hizo clic en él.

Todo lo que he leído hasta ahora sugiere que el POST debe usarse para “acciones destructivas”, mientras que las acciones que no alteran el estado interno de la aplicación, como las consultas y demás, deben manejarse con GET . En base a esto, la verdadera pregunta aquí es:

¿Cerrar la sesión de una aplicación considerada como una acción destructiva / ¿altera el estado interno de la aplicación?

Use POST .

En 2010, usar GET fue probablemente una respuesta aceptable. Pero hoy (en 2013), los navegadores pre-buscarán las páginas que “piensen” que visitarán a continuación.

Aquí está uno de los desarrolladores de StackOverflow hablando sobre este tema en Twitter:

Me gustaría agradecer a mi banco por cerrar sesión una solicitud GET, y al equipo de Chrome por la práctica de captación previa de URL.- Nick Craver ( @Nick_Craver ) 29 de enero de 2013

Dato curioso: StackOverflow solía manejar la desconexión a través de GET, pero ya no.

En REST no debería haber sesión, por lo tanto, no hay nada que destruir. Un cliente REST se autentica en cada solicitud. Conectado, o fuera, es solo una ilusión.

Lo que realmente está preguntando es si el navegador continúa enviando la información de autenticación en cada solicitud.

Posiblemente, si su aplicación crea la ilusión de estar conectado, entonces debería poder “cerrar la sesión” usando javascript. No se requiere viaje redondo.


Fielding Disertation – Sección 5.1.3

cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud y no puede aprovecharse de ningún contexto almacenado en el servidor. El estado de la sesión, por lo tanto, se mantiene completamente en el cliente

Una forma en que se puede abusar de GET aquí es que una persona (competidor quizás 🙂 colocó una etiqueta de imagen con src="" DONDEQUIERA en Internet, y si un usuario de su sitio tropieza con esa página, estará sin saberlo, se desconectó

Para ser correcto, GET / POST (u otros verbos) son acciones en algún recurso (dirigido por URL), por lo que generalmente se trata del estado del recurso y no del estado de la aplicación como tal. Entonces, en verdaderos espíritus, debería tener una URL como [host name]\[user name]\session , luego ‘DELETE’ sería el verbo correcto para la acción de cierre de sesión.

El uso de [host name]\bla bla\logout como URL no es realmente un modo REST completo (IMO), entonces ¿por qué debatir sobre el uso correcto de GET / POST en él?

Por supuesto, también uso GET a una url de cierre de sesión en mis aplicaciones 🙂

Cerrar sesión no le hace nada a la aplicación en sí. Cambia el estado del usuario en relación con la aplicación. En este caso, parece que su pregunta se basa más en cómo debe iniciarse el comando por parte del usuario para comenzar esta acción. Como esto no es una “acción destructiva”, asegúrese de que la sesión se abandone o se destruya, pero ni su aplicación ni sus datos se modifican, no es inviable permitir que ambos métodos inicien un procedimiento de cierre de sesión. La publicación debe ser utilizada por cualquier acción iniciada por el usuario (por ejemplo, el usuario hace clic en Cerrar sesión), mientras que get puede reservarse para inicios de sesión iniciados por la aplicación (por ejemplo, una excepción detectando intrusión de usuario potencial redirige forzadamente a la página de inicio de sesión con un cierre de sesión) )

Hola, en mi punto de vista, cuando inicias sesión, verifica el nombre de usuario / contraseña y si esos coinciden, creas el token de inicio de sesión.

CREAT token => método POST

Cuando cierras sesión, destruyes el token, así que para mí el método más lógico debería ser ELIMINAR

BORRAR token => método DELETE

El escenario de precaching es interesante. Pero supongo que si hay muchos sitios web así que no te preocupes por esto, entonces tal vez tampoco deberías.

¿O quizás el enlace podría implementarse en javascript?

Editar: según tengo entendido, técnicamente un GET debe ser para solicitudes de solo lectura, que no cambian el estado de la aplicación. Un POST debe ser para solicitudes de escritura / edición que cambian de estado. Sin embargo, otros problemas de aplicación podrían preferir GET a POST para algunas solicitudes de cambio de estado, y no creo que haya ningún problema con esto.

Bueno, si dejas que tu aplicación web abandone la sesión mediante un script de finalización de sesión, generalmente tampoco es necesario. Normalmente hay una variable de sesión que es única para la sesión que desea abandonar.

No veo cómo llevar a cabo la depuración (quitar permisos de usuario) es una acción destructiva. Eso es porque la acción de “cierre de sesión” solo debería estar disponible para los usuarios que ya han iniciado sesión, de lo contrario sería obsoleto.

Una cadena generada aleatoriamente contenida en las cookies de su navegador representa a su sesión de usuario. Hay muchas maneras de destruirlo, por lo que cerrar la sesión de manera efectiva es simplemente un servicio para su visitante.