Diferencia entre session y cookies
987 views
Skip to first unread message
IgorJorobus
May 11, 2014, 4:30:16 PM5/11/14
to rub...@googlegroups.com
Pregunta noob chicos, estoy aprendiendo. Alguien puede decirme(y si se explaya un poco se lo voy a agradecer) cual es la diferencia entre las funcionalidades/métodos session y cookies ? Los veo similares, no logro darme cuenta de la diferencia. Gracias!!
Gonzalo Arreche
May 11, 2014, 4:59:52 PM5/11/14
to rub...@googlegroups.com
Buenas!
Básicamente, la diferencia es dónde se guardan.
session se guarda en el servidor y tiene un id asociado, que normalmente se guarda en una cookie (session_id, por ejemplo), pero podrías pasarlo por parámetro.
cookies se guarda en el navegador, el navegador vincula las cookies con el sitio y las manda en cada request. Además, las cookies también son accesibles desde javascript, en el cliente.
cookies se guarda en el navegador, el navegador vincula las cookies con el sitio y las manda en cada request. Además, las cookies también son accesibles desde javascript, en el cliente.
Ya que las cookies se guardan en el navegador, estas son visibles para el usuario, por lo que "no podés" guardar información sensitiva.
Gonzalo.
Pregunta noob chicos, estoy aprendiendo. Alguien puede decirme(y si se explaya un poco se lo voy a agradecer) cual es la diferencia entre las funcionalidades/métodos session y cookies ? Los veo similares, no logro darme cuenta de la diferencia. Gracias!!
--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Angel Java Lopez
May 11, 2014, 5:12:53 PM5/11/14
to rub...@googlegroups.com
Apenas si se escribir un if en ruby.
Pero me imagino que estas preguntando por desarrollo web. En otras tecnologias:
- Session mantiene una lista de valores (generalmente key/value), que puede ser interminable, EN EL SERVIDOR, mientras que algo minimo se mantiene en el browser (con una cookie, con un ID incrustado en el medio de la URL, etc)
- Cookie es clave-valor, pero se guarda en el browser
- Hay un limite de espacio en lo que puede tener una cookie (hmmm... que recuerde, 4k)
- Una cookie (incluido una cookie de session pero es raro) puede sobrevivir hasta una fecha de vencimiento (si la tiene), de otra forma es volatil, solo sobrevive hasta que se cierra el browser
- La session se mantiene en el servidor, en general, hasta que pasa un tiempo sin que haya un cliente browser que venga a usar esa session
- Los valores de session, al estar en el servidor, se guardan en su memoria, o en un repositorio de sesiones. Por ejemplo, se podria guardar en una base de datos, y varios servidores (una granja de servidores web) podria acceder y modificar la misma sesion. Se requiere entonces que clave/valor sean serializables
Algo mas de detalle
http://www.lassosoft.com/Tutorial-Understanding-Cookies-and-Sessions (hmm debe ser PHP, pero no teman, no contagia ;-)
Para Ruby on Rails recien pispie y vi
de hace unos anios, no se si sera asi ahora, pero los conceptos deben sobrevivir
Nos leemos!
Angel "Java" Lopez
@ajlopez
2014-05-11 17:30 GMT-03:00 IgorJorobus <gonzale...@hotmail.com>:
Pregunta noob chicos, estoy aprendiendo. Alguien puede decirme(y si se explaya un poco se lo voy a agradecer) cual es la diferencia entre las funcionalidades/métodos session y cookies ? Los veo similares, no logro darme cuenta de la diferencia. Gracias!!
--
Andrés Arana
May 12, 2014, 12:16:29 AM5/12/14
to rub...@googlegroups.com
Agrego más info conceptual y corrijo algunas cosas. Es largo porque quería explicar el panorama general para enmarcar la respuesta:
1) Una sesión es un concepto bastante abstracto, presente en varios programas (no sólamente web). Vamos a definirlo así: una sesión es un conjunto de interacciones entre un usuario y una aplicación, enmarcado por un evento de "inicio" y uno de "fin". Por ejemplo, me logueo con mi usuario en mi computadora, trabajo durante 3 horas, me deslogueo. No necesariamente los eventos de inicio y fin tienen que ver con la autenticación del usuario. Por ejemplo, varias aplicaciones permiten trabajar en modo "invitado" o "guest", incluyendo algunos sistemas operativos. Por este motivo, en general a los eventos se los denomina "Inicio de sesión" y "Fin de sesión".
2) Una sesión en general acarrea estado entre cada una de las interacciones individuales que la comprenden. Por ejemplo, en las interacciones "me logueo en gmail, mando un mail, me deslogueo", cuando mando el mail, la aplicación recuerda quién soy de cuando me loguié. Esto significa que entre interacción e interacción hay algún tipo de mecanismo que le permite a la aplicación guardar estado (quién soy) en la primer interacción, para después acceder a ese estado en las subsiguientes interacciones.
3) Ahora si, nos metemos en la web. HTTP pelado es un protocolo que no permite almacenar estado entre request y request, lo que significa que entre cada interacción (request en http) no hay forma de mantener estado para los subsiguientes requests de esa sesión. Para poder saltear esta dificultad, HTTP provee un mecanismo en el que en la respuesta de un request se le puede indicar al cliente algo como "a partir de ahora, cada vez que me hagas un request enviame además del request el siguiente dato". Esto permite, por ejemplo, que en el response de la acción de loguearte el server le avise al client "a partir de ahora, adjunta a los próximos requests que me hagas este número de usuario". El dato que se le pide al cliente que reenvie se llama "cookie", y en general está limitado a 4kb por cookie.
4) Como bien dijo Angel, existen distintas políticas de expiración de un cookie, lo que significa que existen estrategías para avisarle al cliente cuando debe dejar de enviar este dato adjuntado. Por ejemplo, se le puede pedir al cliente que envie una cookie durante un tiempo determinado (como durante dos horas, tres días, etc.). Se le puede pedir al cliente que envie una cookie para toda la eternidad. Es importante entender dos cosas: por un lado, el cliente puede decidir dejar de enviar la cookie, dado que el servidor no tiene control de lo que el cliente envía. Por otro lado, el servidor le puede pedir al cliente que deje de enviar una cookie.
5) Ahora si, con todo este conocimiento, nos metemos en los mecanismos "session" y "cookies" de varios frameworks. En general, "session" es un mecanismo a través del cual accedés a datos persistentes entre request y request. Lo importante a entender acá es que es una abstracción sobre cómo se persisten estos datos. Vos metés algo en la session, el framework hace magia y de repente vos podés sacar ese algo en los subsiguientes requests. Una cookie en cambio no es una abstracción en el sentido amplio de la palabra. Cuando metés algo en una cookie, sabés que va a parar al response para avisarle al cliente que cada vez que haga un request adjunte ese algo que metiste usando el mecanismo definido por el estándar, y de esa forma podés acceder a ese algo en los subsiguientes requests.
6) La diferencia entre session y cookies es que la session es una abstracción, y como tal existen diferentes estrategias para implementarla. Pongo algunos ejemplos para que se entienda la idea:
a) Se puede meter todo el contenido que metés en la sessión adentro de una cookie. Cuando metés algo en la session, el framework lo mete encodeado de alguna manera adentro de una cookie. Cuando buscas algo en la session el framework decodifica la cookie y te devuelve lo que estás buscando. Este es el default de rails, por ejemplo.
b) Se puede meter un identificador en una cookie y almacenar lo que metés en la session en un store externo asociado a ese identificador. El cliente envia el identificador en la cookie en los requests, con ese identificador accedes a los registros en el store externo y con eso podés meter y sacar cosas del store. Por ejemplo, puedo tener los contenidos de la session en una base de datos, en una tabla por ejemplo, y el identificador es el id del registro en donde estan guardados los contenidos de la session.
c) Se puede meter un identificador en una cookie y almacenar en memoria lo que metés en la sessión (con un hash, por ejemplo). Cuando viene un request, buscás con el identificador en el hash el contenido de la sesión.
7) Te recomiendo que busques información, ahora que tenés los conceptos, acerca de estas diferentes estrategias para terminar de entender cómo interactuan las cookies con la session y, sobre todo, que ventajas y desventajas tiene cada estrategia en si. Y sobre todo, las estrategías que puse son ejemplos. Son implementaciones bastante naives que tienen grandes desventajas; ponete a leer para entender cuáles son esas desventajas y como corregirlas ahora que tenés el conocimiento general de cómo funciona todo este tema.
Saludos!
1) Una sesión es un concepto bastante abstracto, presente en varios programas (no sólamente web). Vamos a definirlo así: una sesión es un conjunto de interacciones entre un usuario y una aplicación, enmarcado por un evento de "inicio" y uno de "fin". Por ejemplo, me logueo con mi usuario en mi computadora, trabajo durante 3 horas, me deslogueo. No necesariamente los eventos de inicio y fin tienen que ver con la autenticación del usuario. Por ejemplo, varias aplicaciones permiten trabajar en modo "invitado" o "guest", incluyendo algunos sistemas operativos. Por este motivo, en general a los eventos se los denomina "Inicio de sesión" y "Fin de sesión".
2) Una sesión en general acarrea estado entre cada una de las interacciones individuales que la comprenden. Por ejemplo, en las interacciones "me logueo en gmail, mando un mail, me deslogueo", cuando mando el mail, la aplicación recuerda quién soy de cuando me loguié. Esto significa que entre interacción e interacción hay algún tipo de mecanismo que le permite a la aplicación guardar estado (quién soy) en la primer interacción, para después acceder a ese estado en las subsiguientes interacciones.
3) Ahora si, nos metemos en la web. HTTP pelado es un protocolo que no permite almacenar estado entre request y request, lo que significa que entre cada interacción (request en http) no hay forma de mantener estado para los subsiguientes requests de esa sesión. Para poder saltear esta dificultad, HTTP provee un mecanismo en el que en la respuesta de un request se le puede indicar al cliente algo como "a partir de ahora, cada vez que me hagas un request enviame además del request el siguiente dato". Esto permite, por ejemplo, que en el response de la acción de loguearte el server le avise al client "a partir de ahora, adjunta a los próximos requests que me hagas este número de usuario". El dato que se le pide al cliente que reenvie se llama "cookie", y en general está limitado a 4kb por cookie.
4) Como bien dijo Angel, existen distintas políticas de expiración de un cookie, lo que significa que existen estrategías para avisarle al cliente cuando debe dejar de enviar este dato adjuntado. Por ejemplo, se le puede pedir al cliente que envie una cookie durante un tiempo determinado (como durante dos horas, tres días, etc.). Se le puede pedir al cliente que envie una cookie para toda la eternidad. Es importante entender dos cosas: por un lado, el cliente puede decidir dejar de enviar la cookie, dado que el servidor no tiene control de lo que el cliente envía. Por otro lado, el servidor le puede pedir al cliente que deje de enviar una cookie.
5) Ahora si, con todo este conocimiento, nos metemos en los mecanismos "session" y "cookies" de varios frameworks. En general, "session" es un mecanismo a través del cual accedés a datos persistentes entre request y request. Lo importante a entender acá es que es una abstracción sobre cómo se persisten estos datos. Vos metés algo en la session, el framework hace magia y de repente vos podés sacar ese algo en los subsiguientes requests. Una cookie en cambio no es una abstracción en el sentido amplio de la palabra. Cuando metés algo en una cookie, sabés que va a parar al response para avisarle al cliente que cada vez que haga un request adjunte ese algo que metiste usando el mecanismo definido por el estándar, y de esa forma podés acceder a ese algo en los subsiguientes requests.
6) La diferencia entre session y cookies es que la session es una abstracción, y como tal existen diferentes estrategias para implementarla. Pongo algunos ejemplos para que se entienda la idea:
a) Se puede meter todo el contenido que metés en la sessión adentro de una cookie. Cuando metés algo en la session, el framework lo mete encodeado de alguna manera adentro de una cookie. Cuando buscas algo en la session el framework decodifica la cookie y te devuelve lo que estás buscando. Este es el default de rails, por ejemplo.
b) Se puede meter un identificador en una cookie y almacenar lo que metés en la session en un store externo asociado a ese identificador. El cliente envia el identificador en la cookie en los requests, con ese identificador accedes a los registros en el store externo y con eso podés meter y sacar cosas del store. Por ejemplo, puedo tener los contenidos de la session en una base de datos, en una tabla por ejemplo, y el identificador es el id del registro en donde estan guardados los contenidos de la session.
c) Se puede meter un identificador en una cookie y almacenar en memoria lo que metés en la sessión (con un hash, por ejemplo). Cuando viene un request, buscás con el identificador en el hash el contenido de la sesión.
7) Te recomiendo que busques información, ahora que tenés los conceptos, acerca de estas diferentes estrategias para terminar de entender cómo interactuan las cookies con la session y, sobre todo, que ventajas y desventajas tiene cada estrategia en si. Y sobre todo, las estrategías que puse son ejemplos. Son implementaciones bastante naives que tienen grandes desventajas; ponete a leer para entender cuáles son esas desventajas y como corregirlas ahora que tenés el conocimiento general de cómo funciona todo este tema.
Saludos!
Andrés Arana
IgorJorobus
May 13, 2014, 6:35:39 PM5/13/14
to rub...@googlegroups.com
Muchas gracias a todos por las respuestas, me sirvió para comprender.
IgorJorobus
Jun 1, 2014, 1:33:50 PM6/1/14
to rub...@googlegroups.com
Agrego info sacada de Stack Overflow:
"The main difference is that when you use cookie[:foo] = 'bar' the user is able to see the value for the cookie, i.e. 'bar'. When you use session[:foo] = 'bar' the value will be encrypted by rails and stored in the _myapp_session cookie.
You would use the cookie[] format when the information you want to store is not bound to the session, e.g. when the users selects the preferred language.
You would use the session[] format when you want to store information that is related to the current session, e.g. the id of the the user."
Damian Janowski
Jun 1, 2014, 10:08:33 PM6/1/14
to rub...@googlegroups.com
2014-05-11 17:59 GMT-03:00 Gonzalo Arreche <gonzalo...@gmail.com>:
> Buenas!
> Básicamente, la diferencia es dónde se guardan.
Por las dudas, aclaro: no, no es esa la diferencia.
> Buenas!
> Básicamente, la diferencia es dónde se guardan.
La sesión se puede guardar enteramente en una cookie, como por ejemplo
Rack::Session::Cookie [1]. En este caso, el contenido de la cookie se
firma criptográficamente para evitar que alguien pueda manipular su
contenido.
[1]: http://rubydoc.info/github/rack/rack/master/Rack/Session/Cookie
Gonzalo Arreche
Jun 2, 2014, 12:32:44 PM6/2/14
to rub...@googlegroups.com, Damian Janowski
Oops, muy cierto. Siempre me queda la sensación de que la sesión se guarda en el servidor, cosa posible, pero no siempre correcta.
Muchas gracias la aclaración, Damian!
--
Gonzalo Arreche
Gonzalo Arreche
--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
IgorJorobus
Jun 2, 2014, 3:26:53 PM6/2/14
to rub...@googlegroups.com
Creo que lo entendí perfectamente, justo estoy en pleno apogeo de libros.
La session por defecto se guarda en las cookies de cada "visitante" de nuestra web, esta session va encriptada y firmada, es decir que en primer lugar el usuario no puede simplemente "verla", en segundo lugar al estar la session firmada, si el usuario modifica la session manualmente cuando vuelve un request al servidor rails verifica si la firma "es la firma", de otra forma lo ignora.
Si se quiere, se puede sobreescribir este defecto y utilizar otro sistema de persistencia de session, puede ser en una base de datos, DRb, y algunas mas.
Opinan lo mismo?
Reply all
Reply to author
Forward
0 new messages