À quoi sert réellement le domaine session_store :all de Rails 3 ?

Question

Mise à jour de la question pour la rendre plus claire

Je crois savoir que vous pouvez définir le domaine de votre session_store pour partager les sessions entre les sous-domaines comme ceci : Rails.application.config.session_store :cookie_store, :key => '_my_key', :domain => "mydomain.com"

dans Rails 3, que fait le paramètre :domain => :all faire ? Il ne peut pas vous permettre de partager des sessions entre des domaines de premier niveau, les cookies ne peuvent pas le faire. La documentation dit qu'il suppose un seul domaine de premier niveau. Alors que se passe-t-il si plusieurs domaines accèdent à votre application ?

Dans mon application, mes utilisateurs peuvent créer des sous-domaines personnels d'un domaine principal, mais ils peuvent également accéder à ce sous-domaine via leur propre domaine personnalisé.

Quel est le paramètre correct du domaine session_store pour que je puisse : a) partager des sessions entre tous les domaines de mon domaine principal, par exemple "mondomaine.com". b) les utilisateurs qui accèdent à leur sous-domaine personnel, par exemple "user1.mydomain.com", via une url personnalisée CNAME comme "some.otherdomain.com", puissent toujours créer des sessions distinctes.

Gracias

Answer 1

OK, le moyen d'y parvenir est de définir le domaine du cookie de session de manière dynamique. Pour le faire suffisamment tôt, il faut le faire en tant qu'intergiciel 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

Answer 2

Je pense qu'aucune des réponses existantes n'a répondu directement à la question posée dans le titre, alors j'ai voulu apporter ma contribution.

Lorsque le client (navigateur) se rend sur un site web, ce dernier lui demande d'installer un cookie. Ce faisant, il spécifie le nom, la valeur, le domaine et le chemin du cookie.

:domain => :all indique à Rails de placer un point devant le domaine du cookie (qui est l'hôte sur lequel votre navigateur a navigué), de sorte que le cookie s'applique à tous les sous-domaines.

Voici le code correspondant 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

Je vois que vous avez déjà répondu à la deuxième partie de votre question concernant l'autorisation des sous-domaines à avoir des sessions séparées.

Answer 3

tl;dr: Utilisez @Nader Le code de l'entreprise. MAIS j'ai découvert que j'avais besoin de l'ajouter dans mon conifg/environments/[production|development].rb et passer mon domaine préfixé par points comme argument. Ceci est sur Rails 3.2.11

Les sessions de cookies sont généralement stockées uniquement pour votre domaine de premier niveau.

Si vous regardez dans Chrome -> Settings -> Show advanced settings… -> Privacy/Content settings… -> All cookies and site data… -> Search {yourdomain.com} Vous pouvez voir qu'il y aura des entrées séparées pour sub1.yourdomain.com y othersub.yourdomain.com y yourdomain.com

Le défi consiste à utiliser le même fichier de stockage de session dans tous les sous-domaines.

Étape 1 : Utilisez @Nader 's CustomDomainCookie code

C'est là que Middleware en rack vient dans. Quelques autres ressources pertinentes sur les rails et crémaillères :

• Railscasts à propos de Rack
• Railsguide pour Rack
• Documentation du rack pour sesssions de manière abstraite et pour sessions de cookies

En gros, cela permet de faire correspondre toutes les données de votre session de cookies au même fichier de cookies qui correspond à votre domaine racine.

Étape 2 : Ajouter à la configuration Rails

Maintenant que vous avez une classe personnalisée dans la bibliothèque, assurez-vous qu'elle est chargée automatiquement. Si cela ne vous dit rien, regardez ici : Rails 3 autoload

La première chose à faire est de s'assurer que vous utilisez un magasin de cookies à l'échelle du système. Dans config/application.rb nous indiquons à Rails d'utiliser un magasin de cookies.

# We use a cookie_store for session data
config.session_store :cookie_store,
                     :key => '_yourappsession',
                     :domain => :all

La raison pour laquelle il est mentionné ici, c'est à cause de la :domain => :all ligne. D'autres personnes ont suggéré de préciser :domain => ".yourdomain.com" au lieu de :domain => :all . Pour une raison quelconque, cela n'a pas fonctionné pour moi et j'ai eu besoin de la classe Middleware personnalisée comme décrit ci-dessus.

Alors dans votre config/environments/production.rb ajouter :

config.middleware.use "CustomDomainCookie", ".yourdomain.com"

Notez que le point précédent est nécessaire. Voir " des cookies de sous-domaine, envoyés dans une requête du domaine parent ? " pour savoir pourquoi.

Alors dans votre config/environments/development.rb ajouter :

config.middleware.use "CustomDomainCookie", ".lvh.me"

L'astuce lvh.me permet de mapper sur localhost. C'est génial. Voir ce Railscast sur les sous-domaines y cette note pour plus d'informations.

J'espère que ça devrait le faire. Honnêtement, je ne sais pas vraiment pourquoi le processus est si compliqué, car j'ai l'impression que les sites à sous-domaines croisés sont courants. Si quelqu'un a des idées plus précises sur les raisons de chacune de ces étapes, veuillez nous éclairer dans les commentaires.

Answer 4

Cette option est utilisée pour s'assurer que l'application sera capable de partager des sessions entre les sous-domaines. L'option :all suppose que notre application a une taille de domaine de premier niveau de 1. Si ce n'est pas le cas, nous pouvons spécifier un nom de domaine à la place et celui-ci sera utilisé comme domaine de base pour la session.

Answer 5

Hmmm,

Je déploie une application qui est hébergée sous www.xyz.com et sous xyz.com.

Pour moi, :domain => :all définit le domaine du cookie de session à xyz.com. Donc pas pour un domaine de premier niveau mais pour un niveau au-dessus du tld.

Jan Willem