ejemplo - spring session multiple sessions

¿Puedes ayudarme a entender esto? "Errores REST comunes: las sesiones son irrelevantes"

Question

Descargo de responsabilidad: soy nuevo en la escuela de pensamiento REST, y estoy tratando de entenderlo.

Entonces, estoy leyendo esta página, Errores comunes de REST , y he descubierto que estoy completamente desconcertado porque la sección sobre sesiones es irrelevante. Esto es lo que dice la página:

No debería haber necesidad de que un cliente "inicie sesión" o "inicie una conexión". La autenticación HTTP se realiza automáticamente en cada mensaje. Las aplicaciones cliente son consumidores de recursos, no servicios. ¡Por lo tanto, no hay nada para iniciar sesión! Digamos que está reservando un vuelo en un servicio web REST. No crea una nueva conexión de "sesión" al servicio. En cambio, solicite al "objeto creador del itinerario" que cree un nuevo itinerario. Puede comenzar a completar los espacios en blanco, pero luego obtener un componente totalmente diferente en otra parte de la web para completar otros espacios en blanco. No hay sesión, por lo que no hay problema de migrar el estado de la sesión entre los clientes. Tampoco hay problema de "afinidad de sesión" en el servidor (aunque todavía hay problemas de equilibrio de carga para continuar).

De acuerdo, entiendo que la autenticación HTTP se realiza automáticamente en cada mensaje, pero ¿cómo? ¿Se envía el nombre de usuario / contraseña con cada solicitud? ¿Eso no solo aumenta el área de superficie de ataque? Siento que me estoy perdiendo parte del rompecabezas.

¿Sería malo tener un servicio REST, por ejemplo, /session , que acepta una solicitud GET, donde pasaría un nombre de usuario / contraseña como parte de la solicitud, y devuelve un token de sesión si la autenticación fue exitosa, que podría luego pasar junto con las solicitudes posteriores? ¿Eso tiene sentido desde un punto de vista de REST, o es que eso no tiene sentido?

Answer 1

De acuerdo, entiendo que la autenticación HTTP se realiza automáticamente en cada mensaje, pero ¿cómo?

"Autorización:" encabezado HTTP enviado por el cliente. Ya sea básico (texto sin formato) o resumen.

¿Sería malo tener un servicio REST, por ejemplo, / sesión, que acepta una solicitud GET, donde pasaría un nombre de usuario / contraseña como parte de la solicitud, y devuelve un token de sesión si la autenticación fue exitosa, que podría luego pasar junto con las solicitudes posteriores? ¿Eso tiene sentido desde un punto de vista de REST, o es que eso no tiene sentido?

La idea de la sesión es hacer aplicaciones con estado usando el protocolo sin estado (HTTP) y el cliente tonto (navegador web), manteniendo el estado del lado del servidor. Uno de los principios de REST es "Cada recurso es direccionable de manera única utilizando una sintaxis universal para su uso en enlaces hipermedia" . Las variables de sesión son algo a lo que no se puede acceder a través de URI. La aplicación verdaderamente RESTful mantendría el estado del lado del cliente, enviando todas las variables necesarias por HTTP, preferiblemente en el URI.

Ejemplo: búsqueda con paginación. Tendría URL en forma

http://server/search/urlencoded-search-terms/page_num

Tiene mucho en común con las URL favoritas

Answer 2

Creo que su sugerencia es correcta, si desea controlar la vida útil de la sesión del cliente. Creo que la arquitectura RESTful lo alienta a desarrollar aplicaciones sin estado. Como @ 2pence escribió "cada solicitud HTTP debe llevar suficiente información por sí misma para que su destinatario la procese para estar en completa armonía con la naturaleza sin estado de HTTP" .

Sin embargo, no siempre es así, a veces la aplicación necesita indicar cuándo el cliente inicia o cierra la sesión y mantiene recursos como bloqueos o licencias basados ​​en esta información. Vea mi question seguimiento para un ejemplo de tal caso.

Answer 3

Mucha gente no entiende los REST principales muy claramente, usar un token de sesión no significa que siempre tienes estado, la razón para enviar un nombre de usuario / contraseña con cada solicitud es solo para la autenticación y lo mismo para enviar un token (generado por el inicio de sesión) proceso) solo para decidir si el cliente tiene permiso para solicitar datos o no, usted solo viola las convenciones de REST cuando usa un nombre de usuario / contraseña o tokens de sesión para decidir qué datos mostrar. en su lugar, debe usarlos solo para la autenticación (para mostrar datos o no para mostrar datos)

en su caso digo SÍ, esto es RESTy, pero intente evitar el uso de sesiones nativas de php en su API REST y comience a generar sus propios tokens hash que caducan en determinado período de tiempo.

Answer 4

No es raro que un servicio REST requiera autenticación para cada solicitud HTTP. Por ejemplo, Amazon S3 requiere que cada solicitud tenga una firma derivada de las credenciales del usuario, la solicitud exacta para realizar y la hora actual. Esta firma es fácil de calcular en el lado del cliente, puede ser verificada rápidamente por el servidor y es de uso limitado para un atacante que la intercepta (ya que se basa en la hora actual).

Answer 5

No, no se pierde el punto. El ClientLogin de Google funciona exactamente de esta manera con la notable excepción de que el cliente recibe instrucciones para ir a la "sesión" usando una respuesta HTTP 401. Pero esto no crea una sesión, solo crea una forma para que los clientes se autentiquen (temporalmente) sin pasar las credenciales en claro, y para que el servidor controle la validez de estas credenciales temporales como lo considere oportuno.

Answer 6

Para que sea RESTful, cada solicitud HTTP debe llevar suficiente información por sí misma para que su destinatario la procese para estar en completa armonía con la naturaleza sin estado de HTTP.

De acuerdo, entiendo que la autenticación HTTP se realiza automáticamente en cada mensaje, pero ¿cómo?

Sí, el nombre de usuario y la contraseña se envían con cada solicitud. Los métodos comunes para hacerlo son autenticación de acceso básico y autenticación de acceso resumido . Y sí, un espía puede capturar las credenciales del usuario. Por lo tanto, uno encriptaría todos los datos enviados y recibidos utilizando Transport Layer Security (TLS) .

¿Sería malo tener un servicio REST, por ejemplo, / sesión, que acepta una solicitud GET, donde pasaría un nombre de usuario / contraseña como parte de la solicitud, y devuelve un token de sesión si la autenticación fue exitosa, que podría luego pasar junto con las solicitudes posteriores? ¿Eso tiene sentido desde un punto de vista de REST, o es que eso no tiene sentido?

Esto no sería RESTful ya que lleva estado, pero sin embargo es bastante común ya que es una conveniencia para los usuarios; un usuario no tiene que iniciar sesión cada vez.

Lo que describes en un "token de sesión" se conoce comúnmente como cookie de inicio de sesión . Por ejemplo, si intenta ingresar a su Yahoo! cuenta hay una casilla de verificación que dice "mantenerme conectado durante 2 semanas". Esto es esencialmente decir (en sus palabras) "mantener mi token de sesión con vida durante 2 semanas si inicio sesión correctamente". Los navegadores web enviarán esas cookies de inicio de sesión (y posiblemente otras) con cada solicitud HTTP que solicite.