Cerrar sesión: ¿OBTENER o POSTAR?

Esta pregunta no se trata de cuándo usar GET o POST en general; se trata de cuál es el recomendado 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 usar GET, porque implementarlo es mucho más simple que POST; solo suelta un enlace simple y listo. Este parece ser el caso con la gran mayoría de los sitios web en los que puedo pensar, al menos desde lo 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 web / proxies pre-cachean páginas yendo y recuperando cada enlace que encuentran en la página, por lo que el usuario obtiene una respuesta más rápida cuando hace clic en ellos. No estoy seguro de si esto aún se aplica, pero si este fuera el caso, entonces, 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 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:

¿El cierre de sesión de una aplicación se considera una acción destructiva / altera el estado interno de la aplicación?

Uso POST.

En 2010, el uso GETfue probablemente una respuesta aceptable. Pero hoy (en 2013), los navegadores buscarán previamente las páginas que "piensan" que visitará a continuación.

Este es uno de los desarrolladores de StackOverflow que habla sobre este problema en Twitter:

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

Dato curioso: StackOverflow solía manejar el cierre de sesió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 desconectado, 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.

Podría decirse que si su aplicación crea la ilusión de estar conectado, entonces debería poder "cerrar sesión" usando javascript. No se requiere viaje de ida y vuelta.

Disertación de Fielding - 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 aprovechar ningún contexto almacenado en el servidor. Por lo tanto, el estado de la sesión se mantiene completamente en el cliente

Una forma de GETabusar aquí es que una persona (competidor quizás :) colocó una etiqueta de imagen en src="<your logout link>"CUALQUIER LUGAR en Internet, y si un usuario de su sitio tropieza con esa página, se cerrará la sesión sin saberlo.

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, debe tener una URL como [host name]\[user name]\session, entonces 'BORRAR' sería el verbo correcto para cerrar la sesión.

Utilizando [host name]\bla bla\logoutcomo URL no realmente una forma REST completa (IMO), entonces ¿por qué debatir sobre el uso correcto de GET / POST en él?

Por supuesto, también uso GET para cerrar sesión en mis aplicaciones :-)

Cerrar sesión no 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 desde el usuario para comenzar esta acción. Dado que esta no es una "acción destructiva", asegúrese de que la sesión se abandone o destruya pero que no se alteren su aplicación o sus datos, 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 (p. Ej., El usuario hace clic en "Cerrar sesión"), mientras que get se puede reservar para los cierres de sesión iniciados por la aplicación (p. Ej., Una excepción que detecta la posible intrusión del usuario redirige a la página de inicio de sesión con un cierre de sesión GET )

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

CREAR token => método POST

Cuando estás cerrando la sesión, destruyes el token, por lo que para mí el método más lógico debería ser ELIMINAR

DELETE token => método DELETE

El escenario de pre-almacenamiento en caché es interesante. Pero supongo que si muchos sitios inc SO no se preocupan por esto, entonces quizás tampoco debería hacerlo.

¿O tal vez 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. Una POST debe ser para solicitudes de escritura / edición que cambian de estado. Sin embargo, otros problemas de la aplicación pueden preferir GET sobre POST para algunas solicitudes que cambian de estado, y no creo que haya ningún problema con esto.

Bueno, si deja que su aplicación web abandone la sesión a través de un script de cierre de sesión, por lo general, tampoco necesita. Normalmente hay una variable de sesión que es única para la sesión que desea abandonar.

Recientemente estaba trabajando en un proyecto que uso GET para cerrar sesión A continuación se muestra el código en Nodejs Express y funciona perfectamente bien

su router.js

const express = require("express");
router.get("/signout", signout);

su controlador.js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

No veo cómo desconectarse (reducir los permisos de usuario) es una acción destructiva. Esto se debe a que la acción "cerrar sesión" solo debe estar disponible para los usuarios que ya han iniciado sesión; de lo contrario, sería obsoleta.

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