¿Alguien tiene algún consejo de "mejores prácticas" para Rails y sesiones? El tipo de sesión predeterminado para Rails 3 sigue siendo CookieStore, ¿verdad? Usé SqlSessionStore por un tiempo y funcionó bien, pero puedo alejarme de eso a favor de CookieStore.
¿Todavía no es una buena idea usar CookieStore para información confidencial, incluso con información salada o está mejor almacenada en la base de datos?
Respuestas:
Use la base de datos para las sesiones en lugar del valor predeterminado basado en cookies, que no debe usarse para almacenar información altamente confidencial
Crea la tabla de sesiones con
rake db:sessions:create
Ejecuta la migración
rake db:migrate
Asegúrese también de decirle a Rails que use ActiveRecord para administrar sus sesiones también.
config / initializers / session_store.rb:
Rails.application.config.session_store :active_record_store
config / environment.rb:
config.action_controller.session_store = :active_record_store
rake db:sessions:createes obsoleto y eliminado en los carriles 4, ya que no escala bien para aplicaciones con muchos usuarios (demasiados base de datos de lecturas y escrituras). Ver rails 4.0, rake db: sessions: create .
En Rails 4, las cookies de CookieStore están cifradas y firmadas de forma predeterminada:
Si solo ha
secret_tokenconfigurado, sus cookies se firmarán, pero no se cifrarán. Esto significa que un usuario no puede alterar suuser_idsin conocer la clave secreta de su aplicación, pero puede leer fácilmente suuser_id. Este era el valor predeterminado para las aplicaciones Rails 3.Si lo ha
secret_key_baseconfigurado, sus cookies se cifrarán. Esto va un paso más allá que las cookies firmadas, ya que los usuarios no pueden modificar ni leer las cookies cifradas. Este es el inicio predeterminado en Rails 4.Si tiene ambos
secret_tokenysecret_key_baseconfigura, sus cookies se cifrarán y las cookies firmadas generadas por Rails 3 se leerán y cifrarán de forma transparente para proporcionar una ruta de actualización sin problemas.
Esta respuesta ahora está desactualizada con respecto a Rails 4. Active Record Session Store ha quedado obsoleta y se eliminó de Rails, por lo que los siguientes generadores ya no funcionarán:
rake db:sessions:create
rails generate session_migration
Esto se señaló en esta respuesta . La razón por la que Active Record Session Store quedó en desuso es porque las lecturas / escrituras en la base de datos no se escalan bien cuando hay una gran cantidad de usuarios que acceden a su aplicación, como se indica en esta publicación de blog :
... un problema importante con el almacenamiento de sesiones de Active Record es que no es escalable. Pone una carga innecesaria en su base de datos. Una vez que su aplicación recibe una gran cantidad de tráfico, la tabla de la base de datos de sesiones es bombardeada continuamente con operaciones de lectura / escritura.
A partir de Rails 4, el almacén de sesiones de Active Record se eliminó del marco principal y ahora está en desuso.
Si aún desea utilizar Active Record Session Store, todavía está disponible como una joya .
Para conocer las mejores prácticas actuales para las sesiones de Ruby on Rails, le aconsejo que consulte las últimas versiones de la Guía de seguridad de Ruby on Rails .
No creo que haya cambiado nada en la forma en que alguien en cualquier plataforma debe manejar las sesiones basadas en cookies. Sea escéptico ante cualquier cosa que pase más allá del control del servidor (cookies, publicaciones de formularios, etc.). Ese es un principio general del desarrollo web.
En cuanto al cifrado, no sé si algo ha cambiado en ese frente.
Algo a tener en cuenta con un almacén de cookies es el límite de la cantidad de datos, y el problema es que estos datos se enviarán por cable en cada solicitud, mientras que un almacén de bases de datos solo transfiere la identificación y los datos viven en el servidor. .
FWIW, rails 3.1 sugiere ejecutar
rails generate session_migration
Sin embargo, esto genera exactamente la misma migración que
rake db:sessions:create
db:sessions:createahora invoca directamente al session_migrationgenerador. task: create =>: environment do raise "Task no disponible para esta base de datos (sin soporte de migración)" a menos que ActiveRecord :: Base.connection.supports_migrations? requieren 'rieles / generadores' Rails :: Generators.configure! require 'rails / generators / rails / session_migration / session_migration_generator' Rails :: Generators :: SessionMigrationGenerator.start [ENV ["MIGRATION"] || "add_sessions_table"] final
rake db:sessions:createy rails generate session_migrationestán obsoletos y eliminados en Rails 4, porque no escalan bien para aplicaciones con muchos usuarios (demasiadas lecturas y escrituras de bases de datos). Ver rails 4.0, rake db: sessions: create .
Los valores predeterminados de Rails me parecen bastante buenos: CookieStore es rápido y debería cubrir la mayoría de los casos de uso. Seguro que está limitado a 4kb y sus datos serán visibles para el usuario, pero la forma de Rails es usar la sesión solo para cosas como ID de números enteros y valores de cadena básicos, si está intentando almacenar objetos o información altamente confidencial en la sesión probablemente lo estés haciendo mal.