ruby on rails - ¿Qué hace Rails 3 session_store domain: todo realmente?
ruby-on-rails cookies (5)
Pregunta actualizada para que quede más claro
Entiendo que puede configurar el dominio de su session_store para compartir sesiones entre subdominios como este: Rails.application.config.session_store :cookie_store, :key => ''_my_key'', :domain => "mydomain.com"
en Rails 3, ¿qué hace la configuración :domain => :all do? No puede permitirle compartir sesiones en dominios de nivel superior, las cookies no pueden hacerlo. La documentación dice que asume un dominio de nivel superior. Entonces, ¿qué sucede si múltiples dominios acceden a su aplicación?
En mi aplicación, mis usuarios pueden crear subdominios personales de un dominio principal, pero luego también pueden acceder a ese subdominio a través de su propio dominio personalizado.
¿Cuál es la configuración de dominio session_store correcta para poder: a) compartir sesiones en todos los dominios de mi dominio principal, por ejemplo, "mydomain.com" b) usuarios que acceden a su subdominio personal, por ejemplo, "usuario1.midominio.com" a través de un CNAME personalizado url como "some.otherdomain.com" aún puede crear sesiones separadas.
Gracias
Esta opción se usa para garantizar que la aplicación pueda compartir sesiones entre subdominios. La opción: all asume que nuestra aplicación tiene un tamaño de dominio de primer nivel de 1. De lo contrario, podemos especificar un nombre de dominio y se usará como dominio base para la sesión.
Hmmm,
Implemento una aplicación alojada en www.xyz.com y en xyz.com.
Para mí,: domain =>: all establece el dominio de la cookie de sesión en xyz.com. Entonces no para un dominio de nivel superior, sino para 1 nivel por encima del tld.
Jan Willem
No creía que ninguna de las respuestas existentes respondiera directamente a la pregunta en el título, así que quería participar.
Cuando el cliente (navegador) va a un sitio web, el sitio web le dice al cliente que establezca una cookie. Cuando lo hace, especifica el nombre, el valor, el dominio y la ruta de la cookie.
:domain => :all le dice a Rails que ponga un punto delante del dominio de la cookie (que es el servidor al que ha navegado su navegador), de forma que la cookie se aplica a todos los subdominios.
Aquí está el código relevante de Rails 4.1 ( actionpack/lib/action_dispatch/middleware/cookies.rb ):
def handle_options(options) #:nodoc:
options[:path] ||= "/"
if options[:domain] == :all
# if there is a provided tld length then we use it otherwise default domain regexp
domain_regexp = options[:tld_length] ? /([^.]+/.?){#{options[:tld_length]}}$/ : DOMAIN_REGEXP
# if host is not ip and matches domain regexp
# (ip confirms to domain regexp so we explicitly check for ip)
options[:domain] = if (@host !~ /^[/d.]+$/) && (@host =~ domain_regexp)
".#{$&}"
end
elsif options[:domain].is_a? Array
# if host matches one of the supplied domains without a dot in front of it
options[:domain] = options[:domain].find {|domain| @host.include? domain.sub(/^/./, '''') }
end
end
Veo que ya respondió la segunda parte de su pregunta sobre permitir que los subdominios tengan sesiones separadas.
OK, la forma de lograr esto es establecer dinámicamente el dominio en la cookie de sesión. Para hacer esto lo suficientemente temprano, debe hacerse como middleware de rack:
# Custom Domain Cookie
#
# Set the cookie domain to the custom domain if it''s present
class CustomDomainCookie
def initialize(app, default_domain)
@app = app
@default_domain = default_domain
end
def call(env)
host = env["HTTP_HOST"].split('':'').first
env["rack.session.options"][:domain] = custom_domain?(host) ? ".#{host}" : "#{@default_domain}"
@app.call(env)
end
def custom_domain?(host)
host !~ /#{@default_domain.sub(/^/./, '''')}/i
end
end
tl; dr: Usa el código de . PERO encontré que necesitaba agregarlo a mi conifg/environments/[production|development].rb y pasar mi dominio con prefijo de punto como argumento. Esto está en Rails 3.2.11
Las sesiones de cookies generalmente se almacenan solo para su dominio de nivel superior.
Si miras en Chrome -> Settings -> Show advanced settings… -> Privacy/Content settings… -> All cookies and site data… -> Search {yourdomain.com} Puedes ver que habrá entradas separadas para sub1.yourdomain.com y othersub.yourdomain.com y othersub.yourdomain.com
El desafío es usar el mismo archivo de tienda de sesión en todos los subdominios.
Paso 1: use el código CustomDomainCookie
Aquí es donde entra en juego el Rack Middleware . Algunos recursos más relevantes sobre racks y rieles:
- Railscasts sobre Rack
- Railsguide para Rack
- Documentación en bastidor para sesssions de forma abstracta y para sesiones de cookies
Básicamente, lo que hace es mapear todos los datos de la sesión de cookies en el mismo archivo de cookies que es igual a su dominio raíz.
Paso 2: Agregar a Rails Config
Ahora que tienes una clase personalizada en lib, asegúrate de que esté autocargada. Si eso no significaba nada para ti, mira aquí: Rails 3 autoload
Lo primero es asegurarse de estar en todo el sistema utilizando una tienda de cookies. En config/application.rb le decimos a Rails que use una tienda de cookies.
# We use a cookie_store for session data
config.session_store :cookie_store,
:key => ''_yourappsession'',
:domain => :all
La razón por la que esto se menciona aquí se debe a :domain => :all line. Hay otras personas que han sugerido especificar :domain => ".yourdomain.com" lugar de :domain => :all . Por alguna razón, esto no funcionó para mí y necesitaba la clase de Middleware personalizada como se describe arriba.
Luego, en su config/environments/production.rb agregue:
config.middleware.use "CustomDomainCookie", ".yourdomain.com"
Tenga en cuenta que el punto anterior es necesario. Consulte " cookies del subdominio, enviadas en una solicitud de dominio principal " por qué.
Luego, en su config/environments/development.rb agregue:
config.middleware.use "CustomDomainCookie", ".lvh.me"
El truco lvh.me se asigna a localhost. Es impresionante. Vea este Railscast sobre los subdominios y esta nota para más información.
Con suerte eso debería hacerlo. Honestamente, no estoy del todo seguro de por qué el proceso es así de intrincado, ya que creo que los sitios de subdominios cruzados son comunes. Si alguien tiene más información sobre las razones detrás de cada uno de estos pasos, por favor, infórmenos en los comentarios.