2010-11-25 13 views

Respuesta

24

La ventaja para la base de datos o memcached es que los datos de la sesión no se pueden alterar en el lado del cliente y que puede almacenar una cantidad de datos mayor que con las cookies (4kB).

Si su sesión está almacenada en cookies o la base de datos y el servicio web se reinician, los datos de la sesión no se pierden. Solo se puede perder si está almacenado en memcached.

Si el servidor está equilibrado de carga, los datos de la sesión se pasan al servidor web que está atendiendo la solicitud, por lo que esto no es un problema con las cookies, la base de datos o las sesiones de memcached.

La ventaja de las cookies sobre memcached o la base de datos es que el cliente almacena los datos de la sesión, por lo que el servidor no es responsable de ello.

Tenga en cuenta que las cookies de cualquier forma se pasarán al cliente y desde él porque todavía se debe mantener una referencia de sesión.

+0

todo lo que diga es correcto, excepto que "los datos no se pueden alterar". ¿secuestro de sesión? – sethvargo

+3

En el secuestro de sesión, el usuario no está alterando los datos de sesión en el lado del cliente. Están replicando la cookie de identificación de sesión para obtener acceso a un sistema como si fueran el usuario autenticado. –

+0

La sesión almacenada en memcached se perderá después de reiniciar el servidor web? –

18

Las dos razones que se me ocurren son que:

1) Si el servicio web se reinicia, los datos de sesión no se pierde

2) En un entorno de equilibrio de carga, los datos de sesión se almacena en una ubicación central, lo que significa que cualquier servidor puede atender la solicitud y tener acceso a los datos de la sesión.

+0

Quizás. ¿Protege algún tipo de piratería? – Zeck

+2

Parcialmente sí, existen implicaciones de seguridad para almacenar datos de sesión en cookies: http://guides.rubyonrails.org/security.html#session-storage. – bmancini

+1

Con respecto al n. ° 2, el almacenamiento predeterminado basado en cookies también tiene este beneficio. No es que no tenga sus propios problemas, pero este beneficio no es exclusivo del almacenamiento DB/Memcache. – coreyward

7

Hay al menos tres razones que se me ocurren. Si guarda la sesión en la base de datos, puede:

  • acceder fácilmente a cualquier instancia de Rails que ejecute. Entonces, si tiene más de una máquina, no tiene que preocuparse de distribuir los datos de la sesión.
  • No tiene la sesión de límite de sesión de 4kb que solo se aplica cuando se usa el almacén de sesiones de cookies. Aunque se supone que no debe usar la sesión para almacenar objetos, puede que esa funcionalidad algún día.
  • Al utilizar y RDBM (y no Memcached, o cualquier otro almacenamiento no persistente) no tiene que preocuparse por perder datos de sesión.
2

una ventaja menos obvia y pequeña de tener las sesiones en la base de datos es que si necesita contar las sesiones actuales y ver los nombres de otros usuarios conectados es más fácil de implementar que si estuviera usando cookies solo para almacenar datos de sesión o memcached.

+1

porque las aplicaciones web son sin estado, de todos modos no existe una manera confiable de saber cuántos usuarios han iniciado sesión. Las sesiones de conteo no ayudarán con eso. –

+0

Si toca un parámetro updated_at cada vez que carga una página, puede ver cuántas sesiones han cargado algo en los últimos días. Si la cookie de sesión expira en 24 horas, eso le indicará quién todavía está conectado. También puede desconectar personas eliminando sus sesiones. –

2

otra ventaja es para manejar la sesión de caducidad en el lado del servidor como se describe en la sección 2.9:

http://guides.rubyonrails.org/security.html

"Sin embargo, el cliente puede editar las cookies que se almacenan en el navegador web de modo que expira sesiones en el servidor Es más seguro."

class Session < ActiveRecord::Base 
    def self.sweep(time = 1.hour) 
    if time.is_a?(String) 
     time = time.split.inject { |count, unit| count.to_i.send(unit) } 
    end 

    delete_all "updated_at < '#{time.ago.to_s(:db)}' OR 
    created_at < '#{2.days.ago.to_s(:db)}'" 
    end 
end 
Cuestiones relacionadas