Что делает домен Rails 3 session_store: все действительно?

Обновлен вопрос, чтобы сделать его более понятным

Я понимаю, что вы можете установить домен вашего session_store для совместного использования сеансов между подобластями: Rails.application.config.session_store :cookie_store, :key => '_my_key', :domain => "mydomain.com"

в Rails 3, что делает настройка :domain => :all? Он не может позволить вам обмениваться сеансами между доменами верхнего уровня, куки файлы не могут этого сделать. В документации говорится, что он предполагает один домен верхнего уровня. Итак, что происходит, если несколько доменов обращаются к вашему приложению?

В моем приложении мои пользователи могут создавать личные поддомены одного основного домена, но затем могут также получить доступ к этому поддомену через свой собственный домен.

Какова правильная настройка домена session_store, чтобы я мог: а) совместно использовать сеансы во всех доменах моего основного домена, например, "mydomain.com", б) пользователи, которые обращаются к своему личным субдоменам, например, "user1.mydomain.com" с помощью специального URL-адреса CNAME, такого как "some.otherdomain.com", могут создавать отдельные сеансы.

Спасибо

Ответ 1

ОК, способ сделать это - динамически установить домен в файл cookie сеанса. Чтобы сделать это достаточно рано, это должно быть сделано как промежуточное ПО стойки:

# Custom Domain Cookie
#
# Set the cookie domain to the custom domain if it 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

Ответ 2

Я не думал, что какой-либо из существующих ответов напрямую ответил на вопрос в названии, поэтому я хотел почистить.

Когда клиент (браузер) переходит на веб-сайт, веб-сайт сообщает клиенту о настройке файла cookie. Когда он делает это, он указывает имя файла cookie, его значение, домен и путь.

:domain => :all сообщает Rails поставить точку перед доменом cookie (который является тем хостом, который просматривал ваш браузер), так что cookie применяется ко всем субдоменам.

Вот соответствующий код из 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

Я вижу, вы уже ответили на вторую часть своего вопроса о том, чтобы позволить поддоменам иметь отдельные сеансы.

Ответ 3

tl; dr: Используйте @Nader код. НО я обнаружил, что мне нужно добавить его в мой conifg/environments/[production|development].rb и передать мой dot-prefixed-domain в качестве аргумента. Это находится на Rails 3.2.11

Сеансы файлов cookie обычно хранятся только для домена верхнего уровня.

Если вы посмотрите в Chrome -> Settings -> Show advanced settings… -> Privacy/Content settings… -> All cookies and site data… -> Search {yourdomain.com}, вы увидите, что будут отдельные записи для sub1.yourdomain.com и othersub.yourdomain.com и yourdomain.com

Задача состоит в том, чтобы использовать один и тот же файл хранилища сеанса во всех поддоменах.

Шаг 1: используйте @Nader CustomDomainCookie code

Здесь находится Rack Middleware. Еще некоторые релевантные ресурсы стойки и рельсов:

В основном, это означает, что он отобразит все ваши данные сеанса cookie обратно в тот же файл cookie, который равен вашему корневому домену.

Шаг 2: Добавить в Rails Config

Теперь, когда у вас есть пользовательский класс в lib, убедитесь, что он автоматически загружает его. Если это ничего не значит для вас, посмотрите здесь: Автозагрузка Rails 3

Прежде всего, убедитесь, что вы общесистемны, используя хранилище cookie. В config/application.rb мы сообщаем Rails использовать хранилище cookie.

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

Причина, по которой здесь здесь упоминается, связана с линией :domain => :all. Есть другие люди, которые предложили указать :domain => ".yourdomain.com" вместо :domain => :all. По какой-то причине это не сработало для меня, и мне нужен пользовательский класс промежуточного ПО, как описано выше.

Затем в config/environments/production.rb добавьте:

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

Обратите внимание, что предыдущая точка необходима. См. "файлы поддоменов, отправленные в запросе родительского домена?" для чего.

Затем в config/environments/development.rb добавьте:

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

Трюк lvh.me отображается на локальный хост. Это потрясающе. См. этот Railscast о субдоменах и это примечание для получения дополнительной информации Информация.

Надеюсь, это должно сделать это. Я, честно говоря, не совсем уверен, почему этот процесс запутан, поскольку я чувствую, что перекрестные субдомены являются общими. Если у кого-то есть какие-то дальнейшие сведения о причинах, лежащих в основе каждого из этих шагов, пожалуйста, проинформируйте нас в комментариях.

Ответ 4

Эта опция используется, чтобы убедиться, что приложение сможет обмениваться сеансами по субдоменам. Опция: all предполагает, что наше приложение имеет размер домена верхнего уровня 1. Если нет, мы можем вместо этого указать имя домена, которое будет использоваться в качестве базового домена для сеанса.

Ответ 5

Ммм,

Я развертываю приложение, размещенное на www.xyz.com и под xyz.com.

Для меня: domain = > : все устанавливает домен для cookie-сеанса на xyz.com. Так что не для домена верхнего уровня, а для 1 уровня выше tld.

Ян Виллем