architecture - hashtags - instatag
Cerrar sesión: GET o POST? (9)
Bueno, si deja que su aplicación web abandone la sesión a través de un script de cierre de sesión, normalmente tampoco es necesario. Normalmente, hay una variable de sesión que es única para la sesión que desea abandonar.
Esta pregunta no es acerca 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 sencillo que POST; simplemente suelta un simple enlace y listo. Este parece ser el caso de 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 (aunque antiguo) argumento de que algunos aceleradores / proxies web precalean las páginas al ir y recuperar todos los enlaces 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 sigue siendo válido, 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 inicia sesión, ya que su acelerador buscarí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 la POST debería usarse para "acciones destructivas", mientras que las acciones que no alteran el estado interno de la aplicación, como las consultas y demás, deberían manejarse con GET . Basado en 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?
Cerrar sesión no hace nada para la aplicación en sí. Cambia el estado del usuario en relación a 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. Como esta no es una "acción destructiva", la sesión se abandona o se destruye, pero no se modifica su aplicación ni sus datos, no es imposible 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 podría reservarse para las inicios de sesión iniciadas por la aplicación (p. Ej., Una excepción que detecta una posible intrusión de usuarios redirige a la página de inicio de sesión con una sesión GET ).
El escenario de pre-caching es interesante. Pero supongo que si muchos de los sitios no se preocupan por esto, quizás tampoco deberían hacerlo.
O tal vez el enlace podría ser implementado en javascript?
Edición: Como lo entiendo, técnicamente, un GET debe ser para solicitudes de solo lectura, que no cambien el estado de la aplicación. Un POST debe ser para solicitudes de escritura / edición que cambien de estado. Sin embargo, otros problemas de aplicación podrían preferir GET sobre POST para algunas solicitudes de cambio de estado, y no creo que haya ningún problema con esto.
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 haber iniciado sesión, entonces debería poder "cerrar sesión" utilizando javascript. No se requiere 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 sesión se mantiene enteramente en el cliente
Hola, en mi punto de vista, cuando inicia sesión, verifica el nombre de usuario / contraseña y, si coinciden, crea el token de inicio de sesión.
CREAT token => método POST
Cuando estás desconectando, destruyes el token, así que para mí el método más lógico debería ser BORRAR
DELETE token => method DELETE
No veo cómo cerrar la sesión (anular los permisos de los usuarios) es una acción destructiva. Esto se debe a que la acción de "cierre de sesión" solo debería estar disponible para los usuarios que ya hayan iniciado sesión, de lo contrario, estaría obsoleto.
Una cadena generada aleatoriamente contenida en las cookies de su navegador representa a su sesión de usuario. Hay muchas formas de destruirlo, por lo que cerrar sesión de manera efectiva es simplemente un servicio para su visitante.
Para ser correctos, GET / POST (u otros verbos) son acciones en algún recurso (direccionadas por URL), por lo que generalmente se trata del estado del recurso y no del estado de la aplicación como tal. Entonces, en un espíritu verdadero, debe tener una URL como [host name]/[user name]/session , luego ''BORRAR'' sería el verbo correcto para la acción de cerrar sesión.
El uso de [host name]/bla bla/logout como URL no es realmente una forma REST completa (IMO), así que ¿por qué debatir sobre el uso correcto de GET / POST en él?
Por supuesto, también uso GET para una URL de cierre de sesión en mis aplicaciones :-)
Una forma en que se puede abusar de GET aquí es que una persona (competidor quizás :) coloque una etiqueta de imagen con src="<your logout link>" EN CUALQUIER LUGAR en Internet, y si un usuario de su sitio encuentra esa página, será Sin saberlo, se desconectó.
Utilice POST .
En 2010, usar GET fue probablemente una respuesta aceptable. Pero hoy (en 2013), los navegadores pre-buscarán las páginas que "piensan" que visitará a continuación.
Aquí hay uno de los desarrolladores de que habla sobre este problema en Twitter:
Me gustaría dar las gracias a mi banco por hacer que cierre la sesión de una solicitud GET y al equipo de Chrome por la útil búsqueda de URL. Nick Craver ( @Nick_Craver ) 29 de enero de 2013
Dato curioso: solía manejar el cierre de sesión a través de GET, pero ya no.