java - servidor - sockets codigo
¿Cómo funcionan los servidores sin estado? (2)
Intento entender esto Normalmente, cada vez que el usuario inicia sesión en el sistema, el lado del servidor crea una sesión, mientras que el lado del cliente del usuario es la cookie. Cuando la gente habla sobre el lado del servidor sin estado, del lado del cliente, ¿qué significan? lado del servidor sin necesidad de usar la sesión ¿Seguir el usuario? solo usar cookies en el lado del cliente para verificar al usuario? ¿Significa que si cambio el servidor, el usuario no lo notará y aún puede continuar usando el servicio?
¿Cómo configurar Spring-Security para hacer esto?
El seguimiento de un usuario en los servidores es complicado para el verdadero lado del servidor sin estado. La mayoría de las veces las cosas son un servidor sin estado donde los inicios de sesión son la excepción. Sin embargo, el gran problema con los servidores sin estado es que hace que la agrupación sea muy simple para que pueda escalar horizontalmente.
En Java puede hacerlo sin estado utilizando cookies para almacenar credenciales o utilizando hashes distribuidos. En general, las personas aceptan usar algo como Memcache y dicen que son apátridas porque el estado se almacena fuera del servidor web. Eso le permite al usuario usar cualquier servidor web en la granja y aún así ser autenticado de forma segura. En Java tenemos muchas implementaciones hash distribuidas que puedes usar con la primavera para que no tengas que usar Memcache para hacer esto.
La otra opción es usar cookies para almacenar un ticket codificado criptográfico seguro llamado HMAC. El uso de cookies evita el uso de la sesión para que el servidor web no tenga estado. Con HMAC puede firmar un bloque de datos que un tercero no puede falsificar o crear y que se garantiza que se originó de usted. Esto no requiere recursos de servidor externos (el caché) para autenticar al usuario, por lo que puede escalar mejor, pero hay algunas cuestiones de seguridad que debe tener en cuenta. FYI Google usa esta técnica para escalar horizontalmente. Un HMAC no es como SHA1 u otros cyrpto-hashes. Requieren una clave secreta que debe estar en cada servidor de la granja. También debe protegerse con una clave de cifrado simétrica para asegurarse de que esté almacenada de forma segura en el servidor en caso de que alguien se apodere del archivo. Además, la información de HMAC se almacena en forma clara, por lo que si bien puede poner el nombre de usuario o el correo electrónico en la cookie, el hash criptográfico actual está disponible para todos. Si alguien se apodera de esa cookie, podría enmascararse como ese usuario. Es por eso que los HMAC suelen ser válidos solo por una cierta cantidad de tiempo. Después de eso caducan, por lo que si alguien los conoce, no podrán acceder a esa cuenta para siempre.
Así que los HMAC tienen esta debilidad y debes tener cuidado con las aplicaciones en las que los utilizas. Sería una mala idea para Paypal utilizar este esquema porque todo lo que tengo que hacer es obtener tu cookie segura y luego transferir todos tus fondos a mí. El gran beneficio es que su aplicación es verdaderamente apátrida.
La última opción es almacenar sus sesiones de Java en un hash distribuido. Php y otras plataformas descargarán sus sesiones en la base de datos, los pobres tendrán acceso a la memoria caché distribuida, o las depositarán en Memcache. Con Java puedes hacer lo mismo. También puede colocar sus objetos de sesión en la memoria caché distribuida. Esta opción ha caído en desgracia porque la gente piensa "genial ahora puedo volcar lo que quiera en mi sesión y será apátrida". Sin embargo, al igual que con todos los cachés distribuidos, hay límites en la velocidad de transferencia, el tiempo de replicación y el tamaño de la carga útil están vinculados. Esto es cierto para Java o Memcache. Mantenga sus sesiones pequeñas, y esto funciona bien. Pon todo en la sesión y regresa a los problemas de escalado que tienes con un solo servidor. Y realmente es probablemente peor que si acabara de hacer que su servidor fuera con estado porque a veces la computación grid es peor que el servidor único.
Actualización: aquí hay una lista de bibliotecas de almacenamiento en caché distribuidas de Java que puede usar para hacer esto:
http://www.manageability.org/blog/stuff/distributed-cache-java
Un servicio sin estado es un servicio que no almacena datos en el servidor de aplicaciones. Lee o escribe datos en la base de datos, devuelve un valor (o no) y, después de eso, se olvida toda la información sobre la tarea.
Un servicio con estado se usa para realizar transacciones, es decir, una serie de tareas que dependen del resultado de las tareas anteriores. El ejemplo más fácil es enviar un pedido a una tienda web, donde reúne sus productos en un carrito de compras, y cuando realiza el pago, ingresa los datos de su cuenta en una página, la almacena, luego ingresa su dirección de facturación, la almacena, luego confirme su pedido y concluya la transacción. Cada paso depende del resultado exitoso del paso anterior, y los datos deben conservarse hasta que se complete el último de estos pasos o se cancele la transacción, en cuyo caso tiene que haber una reversión para restablecer el saldo de su cuenta al modo fue antes de que se marchara.
En la mayoría de los casos, puede implementar transacciones en ambos sentidos, pero si tuviera que usar servicios apátridas, su aplicación cliente tendría que encargarse del manejo correcto y la finalización de las tareas, o tendría que encontrar otra forma de almacenar el información de transacción correctamente y administrar las reversiones. Eso sería un lado del cliente con estado , como lo llamaste.
Todo esto es, sin embargo, bastante general, y la seguridad y / o el manejo de la sesión deberían tenerse en cuenta en cada uno de esos casos. Puede utilizar la información de sesión para autenticar llamadas de servicio sin estado; solo deberá autenticar cada llamada individualmente, por ejemplo, adjuntando un ID de sesión o de usuario o algún otro token de seguridad a los datos de la empresa.