¿Qué método debo utilizar para una solicitud de inicio de sesión (autenticación)?


93

Me gustaría saber qué método http debo usar al realizar una solicitud de inicio de sesión y por qué. Dado que esta solicitud crea un objeto (una sesión de usuario) en el servidor, creo que debería ser POST, ¿qué opinas? Pero dado que la solicitud de inicio de sesión debe ser idempotente, podría ser PUT, ¿no?

La misma pregunta para una solicitud de cierre de sesión, ¿debo usar el método DELETE?

Respuestas:


77

Si su solicitud de inicio de sesión es a través de un usuario que proporciona un nombre de usuario y contraseña, entonces es preferible una POST, ya que los detalles se enviarán en el cuerpo de los mensajes HTTP en lugar de la URL. Aunque todavía se enviará como texto sin formato, a menos que esté encriptando a través de https.

El método HTTP DELETE es una solicitud para eliminar algo en el servidor. No creo que BORRAR una sesión de usuario en memoria sea realmente lo que se pretende; más es para borrar el propio registro de usuario. Por lo tanto, el cierre de sesión puede ser solo un GET, por ejemplo, www.yoursite.com/logout.


1
Con respecto a la solicitud de inicio de sesión, agregué algo a mi pregunta diciendo que podría ser PUT, no dudaba con GET. +1 para la respuesta detallada
greg0ire

1
ok, creo que PUT realmente está creando algo en el servidor. Entonces, en un sentido RESTful, supongo que eso es lo que PODRÍA usar si crea un nuevo usuario. Y el usuario debe crearse en la URL que especifique. Sin embargo, para algo que sea realmente transitorio como una sesión http, entonces iniciaría sesión a través de POST.
planetjones

Creo que el hecho de que la sesión http sea transitoria lo demuestra. Voy a hacer lo que dijiste, gracias.
greg0ire

16
No estoy de acuerdo con que LOGOUT deba ser OBTENER porque simplemente enviando un correo electrónico de usuario con una etiqueta de imagen que tiene su atributo src como "www.yoursite.com/logout" cerrará la sesión de ese usuario.
Vytautas Butkus

2
GET no tiene mucho sentido. Puede encontrar otra entrada sobre esto aquí: stackoverflow.com/questions/3521290/logout-get-or-post
thasmo

37

Creo que puede traducir los métodos LOGIN & LOGOUT en operaciones CRUD básicas CREATE & DELETE. Dado que está creando un nuevo recurso llamado SESSION y lo destruye al cerrar la sesión:

  1. POST / iniciar sesión: crea una sesión
  2. DELETE / logout - destruye la sesión

Nunca haría LOGOUT como GET solo porque cualquiera podría realizar un ataque simplemente enviando un correo electrónico con una etiqueta IMG o un enlace al sitio web donde existe dicha etiqueta IMG. ( <img src="youtsite.com/logout" />)

PD Hace mucho tiempo que me preguntaba cómo crearía un inicio de sesión / cierre de sesión RESTful y resultó que es realmente simple, lo hace como lo describí: use / session / endpoint con los métodos CREATE y DELETE y está bien. También puede usar ACTUALIZAR si desea actualizar la sesión de una forma u otra ...


4
Es casi tan fácil hacer una solicitud DELETE como una solicitud GET con herramientas de navegador modernas, algunas de las cuales están disponibles directamente en el navegador, como emitir una solicitud XHR directamente desde la consola del navegador. Todavía votó a favor porque habló de semántica, que también es importante, así como de base de datos.
Trysis

6

Aquí está mi solución basada en guías y recomendaciones REST:

LOGIN - crea un recurso

Solicitud:

POST => https://example.com/sessions/

BODY => {'login': 'login@example.com', 'password': '123456'}

Respuesta:

http status code 201 (Created)

{'token': '761b69db-ace4-49cd-84cb-4550be231e8f'}

SALIR - eliminar un recurso

Solicitud:

DELETE => https://example.com/sessions/761b69db-ace4-49cd-84cb-4550be231e8f/

Respuesta:

http status code 204 (No Content)

2

En cuanto al método para cerrar la sesión:

En la documentación de Spring (Java Framework), afirman que se prefiere una solicitud POST, ya que un GET lo hace vulnerable a CSRF (Cross-Site Request Forgery) y el usuario podría cerrar la sesión.

Agregar CSRF actualizará LogoutFilter para usar solo HTTP POST. Esto asegura que el cierre de sesión requiera un token CSRF y que un usuario malintencionado no pueda cerrar la sesión de sus usuarios por la fuerza.

Ver: https://docs.spring.io/spring-security/site/docs/current/reference/html/web-app-security.html#csrf-logout

El inicio de sesión también debe usar POST (el cuerpo se puede cifrar, consulte las otras respuestas).


0

Para la solicitud de inicio de sesión, debemos usar el método POST. Porque nuestros datos de inicio de sesión son seguros, lo que necesita seguridad. Cuando se usa el método POST, los datos se envían al servidor en un paquete. Pero en el método GET, los datos se envían al servidor seguidos de la URL, como agregar con la solicitud de URL, que será vista por todos.

Entonces, para un proceso seguro de autenticación y autorización, debemos usar el método POST.

Espero que esta solución te ayude.

Gracias


0

Para iniciar sesión, uso POST, a continuación se muestra mi código para el método LOGIN que usé Nodejs con Express y Mongoose

your router.js
     const express = require("express");
     const router = express.Router();

     router.post("/login", login);

your controller.js
     export.login = async(req, res) => {
         //find the user based on email
         const {email, password} = req.body; 

           try{
                const user =  awaitUser.findOne({email});
                if(user==null) 
                 return res.status(400).json({err : "User with 
                         email doesnot exists.Please signup"});
          }
           catch(error){
                 return res.status(500).json({err : 
                                     error.message});
               }

         //IF EVERYTHING GOES FINE, ASSIGN YOUR TOKEN
          make sure you have JWT installed 
         const token = jwt.sign({_id: user._id}, YOUR_SECRET_KEY);

         res.cookie('t');

         const {_id, name, email} = user;
         return res.json({token, user : {_id, email, name}});



     }
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.