Esta puede ser una pregunta complicada, pero estoy tratando de comprender mejor la apatridia.
Según lo que he leído, las aplicaciones web no deberían tener estado, lo que significa que cada solicitud se trata como una transacción independiente. Como resultado, se deben evitar la sesión y las cookies (ya que ambas tienen estado). Un mejor enfoque es usar tokens, que no tienen estado porque no hay nada almacenado en el servidor.
Así que estoy tratando de entender, ¿cómo pueden las aplicaciones web no tener estado cuando hay datos que se guardan para mi sesión (como artículos en un carrito de compras)? ¿Se almacenan realmente en una base de datos en algún lugar y luego se purgan periódicamente? ¿Cómo funciona esto cuando estás usando un token en lugar de cookies?
Y luego, como pregunta relacionada, ¿son los principales sitios web (Amazon, Google, Facebook, Twitter, etc.) realmente apátridas? ¿Utilizan tokens o cookies (o ambos)?
Respuestas:
"las aplicaciones web deben estar sin estado" deben entenderse como "las aplicaciones web deben estar sin estado a menos que haya una muy buena razón para tener estado" . Un "carrito de compras" es una característica con estado por diseño, y negar eso es bastante contraproducente. El objetivo del patrón del carrito de compras es preservar el estado de la aplicación entre solicitudes.
Una alternativa que podría imaginar como un sitio web sin estado que implementa un carrito de compras sería una aplicación de una sola página que mantiene el carrito de compras completamente del lado del cliente, recupera información del producto con llamadas AJAX y luego la envía al servidor de una vez cuando El usuario realiza un pago. Pero dudo que haya visto a alguien realmente hacer eso, porque no permite al usuario usar múltiples pestañas del navegador y no conserva el estado cuando cierra accidentalmente la pestaña. Claro, existen soluciones alternativas como el uso de almacenamiento local, pero luego tiene estado nuevamente, solo en el cliente en lugar del servidor.
Siempre que tenga una aplicación web que requiera conservar datos entre páginas vistas, generalmente lo hace introduciendo sesiones. La sesión a la que pertenece una solicitud se puede identificar mediante una cookie o mediante un parámetro de URL que agregue a cada enlace. Deben preferirse las cookies porque mantienen sus URL más útiles y evitan que su usuario comparta accidentalmente una URL con su ID de sesión. Pero tener tokens de URL como alternativa también es vital para los usuarios que desactivan las cookies. La mayoría de los marcos de desarrollo web tienen un sistema de manejo de sesión que puede hacer esto de forma inmediata.
En el lado del servidor, la información de la sesión generalmente se almacena en una base de datos. El almacenamiento en caché en memoria del lado del servidor es opcional. Puede mejorar enormemente el tiempo de respuesta, pero no le permitirá transferir sesiones entre diferentes servidores. Por lo tanto, necesitará una base de datos persistente como alternativa.
¿Te permiten iniciar sesión? Cuando cierra la pestaña y vuelve a visitar el sitio, ¿todavía está conectado? Si es así, están utilizando cookies para preservar su identidad entre sesiones.
fuente
Es cierto que las aplicaciones web deberían ser apátridas. Sin embargo, las variables de sesión, las cookies y los tokens no violan esto cuando se almacenan en el cliente (navegador web). Pueden ser parámetros en la solicitud.
Aquí hay un modelo simplificado:
Esto podría funcionar para el intercambio de pila de ingeniería de software . Esta respuesta que estoy escribiendo es parte del estado de mi navegador web. Mientras ese sea el único lugar donde esté, no es accesible para nadie más que para mí. Pero tan pronto como llego a
Post your Answermi navegador, lo envía al servidor web. El servidor web procesa la publicación sin ningún estado propio. Aprende quién soy desde mi navegador y desde la base de datos. Una vez que haya terminado de revisar mi publicación y agregarla a la base de datos, el servidor web se olvida rápidamente de mí.Eso es lo que significa apátrida. El servidor no es responsable de recordar nada de esto. Ese no es su trabajo.
Hacer esto tiene muchas ventajas. Si el servidor web tiene una pérdida de memoria, es detectable ya que su huella de memoria no debería estar creciendo. Si el servidor web falla, mi identidad no va con él. Si alguien intenta hacer un ataque de denegación de servicio, no puede usar los recursos de estado del servidor web para hacerlo, porque el servidor web no les asigna ningún estado entre sesiones. Todo esto tiene como objetivo hacer que el servidor web sea estable. De esa manera, cuando comienza a funcionar, permanece en funcionamiento.
Ahora claro, estoy consumiendo recursos en la base de datos, pero esos recursos se han verificado primero con mi asignación por algo estable con el que podemos contar para proteger la base de datos de la web salvaje y laberíntica: el servidor web sin estado que hace cumplir las reglas comerciales.
fuente
Disparates. Las solicitudes web deben ser apátridas. O más exactamente, las solicitudes web no tienen estado.
Pero decir que toda una aplicación debería ser apátrida no tiene sentido.
Si exactamente . O más exactamente, sí, necesariamente . Sobre HTTP, cada solicitud es inherentemente independiente de todas las demás solicitudes. Agregar "estado" a HTTP requiere que identifique, almacene y recupere explícitamente el "estado" para cada solicitud "con estado". Y eso requiere esfuerzo, disminuye el rendimiento y agrega complejidad.
Y, por esas razones, cada solicitud que puede ser apátrida "debería" ser apátrida.
Algunas cosas: los tokens también pueden vincularse al almacenamiento de la sesión. Las cookies no necesitan estar vinculadas al almacenamiento de la sesión. Los tokens a menudo se almacenan en cookies. Y, a veces, una sesión es simplemente la herramienta adecuada para el trabajo.
¡Eso significa que al menos a veces , las sesiones y las cookies son tan "mejores" como los tokens!
Bueno, eso es todo. De eso se trata realmente el dogma de la "apatridia". Sin embargo, para ser claros, no se trata de almacenar "nada" en el servidor, se trata de no almacenar el estado de la sesión en el servidor.
Mi bandeja de entrada de Gmail está en un estado, por ejemplo. ¡Y es mejor que se almacene en el servidor! Pero, no es estado de sesión .
Por lo tanto, en lugar de tener un servidor que pueda tomar un pequeño identificador y descubrir quién es, etc., las aplicaciones sin estado desean que se les recuerde quién es usted y qué está haciendo con cada solicitud sangrienta. El estado de la aplicación aún existe, el cliente solo es responsable de retenerlo.
Ahora, si ese estado es pequeño, probablemente esté bien. En algunos casos es muy bueno.
Y luego, por supuesto, hay cosas que simplemente esperamos que tengan estado ...
Dos opciones. ¡O tienes una sesión, o estás en negación!
... Pero en serio. Normalmente no almacenarías un carrito en una galleta. Algo así como un carrito de compras se almacenará en una sesión "tradicional", o se almacenará como un
Cartobjeto, con algún tipo de identificación que el servidor usa para atraerlo a solicitudes posteriores. Algo así como una ... uhh ... ... err ... sesión.Realmente en serio: hay un gran grado en que la "capacidad de estado" es exactamente lo que llamamos cuando dos agentes comunicantes pueden contextualizar los mensajes en una conversación. Y una sesión, entendida tradicionalmente, es justo lo que típicamente llamamos el mecanismo por el cual esto ocurre.
Yo diría que, independientemente de si usa tokens o "sesiones", para cada solicitud que maneja su servidor, debe contextualizar esa solicitud para cumplirla o no. Si el contexto no es necesario, no lo traigas. Si el contexto es necesario, ¡ es mejor que lo tenga cerca!
Probablemente ambos. Pero, en términos generales, hacen exactamente lo que usted hace: establecen cookies para identificar registros de "estado" en bases de datos masivas de "sesión".
Cuando es posible, sospecho que colocan las afirmaciones básicas de identidad en "tokens" de corta duración para evitar una contención innecesaria en el almacenamiento centralizado. Pero el hecho de que muchos de estos servicios me permitan "cerrar sesión en todas las demás ubicaciones" es un buen indicador de que, si están usando tokens, al menos están "respaldados" por un modelo de sesión semi-tradicional .
fuente
La capacidad de estado no es necesariamente algo malo, pero debe comprender la diferencia entre las aplicaciones con estado y sin estado. En resumen, las aplicaciones con estado mantienen información sobre la sesión actual, y las aplicaciones sin estado no. La información almacenada permanentemente como parte de una cuenta de usuario puede o no almacenarse en una sesión, pero el almacenamiento de información relacionada con una cuenta de usuario no hace que la aplicación tenga estado. La capacidad de estado requiere que el servidor mantenga información sobre la sesión del usuario actual más allá de lo que mantiene el navegador del cliente. Por ejemplo, un cliente podría autenticarse y recibir una cookie JSESSIONID, que luego envía al servidor con cada solicitud. Si el servidor comienza a almacenar cosas en el alcance de la sesión de la aplicación en función de este JSESSIONID, se vuelve con estado.
Apatridia
Por apátrida, queremos decir que el servidor y el cliente no mantienen información actual sobre la sesión del usuario. El cliente y el servidor pueden usar alguna forma de token para proporcionar autenticación entre solicitudes, pero no se almacena ninguna otra información actual. Un caso de uso típico para una solución de este tipo podría ser un sitio de noticias donde la mayoría de los usuarios (nuevos consumidores) consumen información pero no producen información que regrese al sitio. En tales casos, el sitio no necesita mantener ninguna información sobre la sesión de usuario actual. Tenga en cuenta que el sitio aún puede usar cookies para identificar al usuario y almacenar información sobre el uso del sitio por parte de ese usuario, pero aún puede considerarse como apátrida ya que todo lo registrado podría ser transaccional, por ejemplo, en qué enlace hizo clic el usuario, que podría registrar el servidor, pero no se mantiene en una sesión de usuario.
Statefulness en el servidor
En el servidor, una aplicación con estado guarda información de estado sobre los usuarios actuales. Este enfoque generalmente implica el uso de cookies para identificar el sistema del usuario para que el estado se pueda mantener en el servidor entre las solicitudes. Las sesiones pueden o no ser autenticadas, dependiendo del contexto de la aplicación. Las aplicaciones de servidor con estado ofrecen la ventaja de almacenar en caché la información del estado del usuario en el servidor, acelerando las búsquedas y el tiempo de respuesta de la página. En el lado negativo, el almacenamiento de información en el alcance de la sesión es costoso y, a escala, requiere muchos recursos. También crea un potencial vector de ataque para que los hackers intenten secuestrar identificadores de sesión y robar sesiones de usuario. Las aplicaciones de servidor con estado también tienen el desafío de proteger las sesiones de los usuarios contra interrupciones inesperadas del servicio, por ejemplo, una falla del servidor.
Statefulness en el cliente
Mediante el uso de JavaScript y tecnologías de navegador modernas como sessionStorage, la aplicación ahora puede almacenar fácilmente información de estado sobre una sesión de usuario en el dispositivo de ese usuario. En general, la aplicación aún puede considerarse con estado, pero el trabajo de mantener el estado se ha trasladado al cliente. Este enfoque tiene una gran ventaja (para el responsable del mantenimiento de la aplicación web) sobre el mantenimiento del estado en el servidor, ya que cada usuario mantiene, en efecto, su propio estado y no supone una carga para la infraestructura del servidor. A escala web, ese tipo de elección arquitectónica tiene enormes repercusiones para los costos de hardware y electricidad. Literalmente, podría costar millones de dólares al año mantener el estado en el servidor. Pasar a un sistema que mantenga el estado del cliente podría ahorrar millones de dólares al año.
Tokens v. Cookies
Las cookies actúan como identificadores para los dispositivos / navegadores del cliente. Se pueden usar para almacenar todo tipo de cosas, pero generalmente almacenan algún tipo de identificador, como CFID / CFTOKEN en aplicaciones CFML. Las cookies se pueden configurar para que vivan en el navegador del usuario durante mucho tiempo, lo que permite hacer cosas como mantener la autenticación en una aplicación entre las sesiones del navegador. Las cookies también se pueden configurar en memoria solamente para que caduquen cuando un usuario cierra el navegador.
Los tokens son generalmente algún tipo de información de identificación sobre el usuario que se genera en el servidor (utilizando cifrado para codificar la información), se pasa al cliente y se devuelve al servidor con la solicitud posterior. Se pueden pasar en el encabezado de la solicitud y la respuesta, que es un patrón común en aplicaciones de una sola página. Idealmente, cada solicitud / respuesta da como resultado la generación de un nuevo token, por lo que los tokens no pueden ser interceptados y utilizados más tarde por un atacante.
Aplicaciones de página única y estado del cliente
Con los SPA, la información de estado se carga en el navegador del cliente y se mantiene allí. Cuando el estado cambia, por ejemplo, publica una actualización en su cuenta de redes sociales, el cliente transmite esa nueva transacción al servidor. En este caso, el servidor guarda esa actualización en un almacén de datos persistente como una base de datos y retransmite cualquier información al cliente que necesita sincronizar con el servidor en función de la actualización (por ejemplo, una ID para la actualización).
Tenga en cuenta que este patrón de estado de almacenamiento en el cliente ofrece ventajas para las experiencias en línea / fuera de línea, ya que puede desconectarse del servidor mientras aún tiene una aplicación algo utilizable. Twitter es un buen ejemplo de este caso, donde puedes revisar cualquier cosa cargada del lado del cliente en tu feed de Twitter, incluso si estás desconectado de la aplicación del servidor de Twitter. Este patrón también crea complejidad en la sincronización entre el servidor y el cliente, que es un tema completamente propio. Las complejidades de la solución son una compensación para poder mantener el estado del cliente.
La capacidad de representación en el cliente hace que las aplicaciones web se sientan y se comporten más como las aplicaciones de escritorio tradicionales. A diferencia de las aplicaciones de escritorio, normalmente no tendrá toda la información de su cuenta cargada en su sesión de cliente en un navegador. Hacerlo en muchos casos sería poco práctico y produciría malas experiencias. ¿Te imaginas intentar cargar un cuadro completo de Gmail en el navegador? En cambio, el cliente mantiene información como qué etiqueta / carpeta está mirando y en qué parte de la lista de correos electrónicos de esa carpeta está mirando. Equilibrar qué información de estado mantener y qué solicitar según sea necesario es otro desafío de ingeniería de este patrón, y nuevamente, representa una compensación entre la practicidad y la provisión de buenas experiencias de usuario.
Carritos de compras y similares
En cuanto a detalles como los carritos de compras, realmente depende de la solución. Un carrito de compras puede almacenarse en una base de datos en el servidor, puede almacenarse solo en el alcance de la sesión en el servidor, o incluso puede almacenarse en el cliente. Amazon tiene carritos de compra persistentes para usuarios registrados y carritos "temporales" para usuarios anónimos, aunque estos carritos son persistentes en cierta medida.
Cuando se habla de algo como Google, que en realidad es un conjunto de aplicaciones diferentes que viven bajo la misma marca, probablemente no comparten una arquitectura común, y cada una está construida de la manera que mejor satisfaga las necesidades de sus usuarios. Si desea aprender cómo se construye un sitio, abra las herramientas de desarrollador en su navegador y mírelo. Compruebe si hay cookies, observe el tráfico de la red y vea cómo se ejecuta.
Lo siento si esta respuesta divaga un poco, pero la afirmación es un tema complejo.
fuente
No es necesario evitar las sesiones y las cookies. Todavía puede tenerlos con aplicaciones web sin estado.
Hay una gran diferencia entre Java y Ruby on Rails. Las aplicaciones Java almacenarán la sesión en la memoria utilizando una clave de sesión almacenada en una cookie. Esto es rápido para recuperar el estado del usuario y el carrito de compras. Sin embargo, siempre debe presionar el mismo servidor con su sesión.
Las aplicaciones de Rails almacenan la identificación del usuario en una cookie firmada y encriptada. No puede ser manipulado. Cuando carga una página, la aplicación web obtiene su estado, usuario y carrito de compras de una base de datos. ¡Esto es más lento, pero la clave es que puedes golpear cualquier instancia ! Esto le permite reiniciar, escalar, cerrar instancias a voluntad. Muy conveniente. También se puede hacer más rápido con una base de datos de caché compartida en memoria como Redis. O puede almacenar el carrito de compras en la cookie, siempre que sea lo suficientemente pequeño.
Para que pueda lograr la apatridia, a través de técnicas inteligentes, y agregar la capacidad de escalar a voluntad.
fuente
El protocolo no tiene estado.
Pero a partir de eso, no necesariamente se deduce que las aplicaciones que usan el protocolo no tengan estado.
Aquí hay un par de respuestas relacionadas de StackOverflow que explican bien la diferencia:
fuente
Cuando se hace referencia a sin estado, por ejemplo, en un servicio HTTP RESTful, se trata de evitar almacenar el estado en el lado del servidor. En el mejor de los casos, eso incluye también evitar el almacenamiento de cualquier estado en una base de datos u otros almacenamientos persistentes en el back-end. Para que quede claro, estoy hablando de un estado, no de datos en general. Parece que algunos chicos están mezclando cosas.
Una comunicación sin estado tiene varios beneficios, especialmente con respecto a la escalabilidad y la disponibilidad.
Eso es cierto (para ciertos protocolos de autenticación y autorización). Los tokens pueden (pero no per se) proporcionar toda la información dentro de la solicitud que se necesita para autenticar a un usuario o autorizar una acción. Por ejemplo, eche un vistazo a JWT .
En cuanto al ejemplo del carrito de compras. No es ningún problema almacenar todos los artículos del carrito en el lado del cliente sin usar una sesión o cookies. Puede encontrar un ejemplo en smashingmagazine.com . Pero también es posible realizar un carrito de compras sin estado con cookies (al menos si su surtido no es tan grande y 4kb de almacenamiento es suficiente para usted).
No me malinterpreten, eso no significa que deba implementar un carrito de compras sin estado a cualquier precio. Amazon u otras grandes plataformas de compras en línea están utilizando implementaciones de carrito de compras con estado porque la experiencia del usuario y la usabilidad son más importantes para ellos que el ajuste de requisitos técnicos no funcionales como la escalabilidad.
En general, los tokens no se usan para almacenar información como artículos de carrito. Se utilizan para una autenticación y autorización sin estado.
Si está preguntando si están usando cookies o tokens para la autenticación, la respuesta es que usan ambos. Para los usuarios, en su mayoría se utilizan cookies para clientes técnicos, en su mayoría tokens.
fuente
OK, la regla que cita es técnicamente incorrecta. Todas las capas de una aplicación web tienen estado.
La intención de la regla es "no mantener el lado del servidor de estado por sesión".
Es decir, variables de sesión en ASP , que se usaban comúnmente para hacer cosas como elementos en la cesta / nombre de usuario, etc.
La razón es que se quedará sin memoria en el servidor a medida que su aplicación gane más usuarios. Mover el almacenamiento a una base de datos o caché compartida no resuelve el problema, ya que todavía tiene un cuello de botella.
Para mantener el estado de la aplicación por usuario sin encontrar este problema, mueva el estado al lado del cliente. Por ejemplo, coloque los elementos de la cesta en una cookie o en un almacenamiento más avanzado del lado del cliente.
Debido a que el número de clientes aumenta con el número de usuarios, su aplicación en su conjunto no tendrá un cuello de botella y se escalará bien.
fuente