Можно ли указать две корневых страницы в Rails (одна для анонимного пользователя, другая для авторизованного пользователя)

Question

Я создаю продукт, который имеет статические и динамические страницы (связанные с продуктом). Обе категории страниц имеют разный жизненный цикл. Команда маркетинга, работающая с дизайнером, выпускает статические страницы, а страницы продукта выпускаются командой инженеров.

Статические страницы находятся в public/home и являются автономными. Им не нужен доступ к инфраструктуре Rails, кроме предоставления ссылок.

В этой настройке я пытаюсь реализовать следующее поведение:

• Когда пользователь, не прошедший проверку подлинности, запускает http://www.xyz.com,, пользователь должен перейти на статическую целевую страницу.

• Когда пользователь, прошедший проверку подлинности, запускает http://www.xyz.com,, пользователь должен перейти на целевую страницу продукта (LandingsController, index action).

В моей текущей реализации я проверяю, прошел ли пользователь аутентификацию в мире Rails, и отображаю статическую страницу ИЛИ страницу продукта.

Я хочу знать следующее:

1) Как вы справляетесь с такими сценариями?

2) Есть ли способ избежать входа в стек Rails для статической домашней страницы.

3) Есть ли настройка метода root_path для возврата другого корня в зависимости от контекста

Answer 1

1) Как вы справляетесь с такими сценариями?

Общий ответ будет выглядеть так:

class LandingsController < ApplicationController

  before_filter :login_required

  def index
    ...
  end

  ...

  private

    def login_required
      if not_logged_in? # This methods depends on your authentication strategy
        send_file "/your/static/path/#{params[:action]}", :type => "application/html charset=utf8;"
        return false # Halt chain
      end
    end

документация send_file

И, в зависимости от соответствия между каждым вашим действием и вашими шаблонами, вы можете дополнительно абстрагировать метод login_required в ApplicationController и проверить, существует ли файл.

2) Есть ли способ избежать входа в стек Rails для статических страниц

Да. Вы должны поверить мне на слово, потому что я сам этого не сделал, но вы можете использовать промежуточное программное обеспечение Rack для этого. Вот пример того, как сделать что-то подобное, за исключением того, что вместо перенаправления файл будет обслуживаться статически (просто задайте заголовки и результаты File.read как содержимое). Это зависит от тем не менее, библиотека аутентификации, с которой вы работаете.

3) Есть ли настройка для метода root_path, чтобы он возвращал разные корень на основе контекста

Вы не можете определить условный маршрут (т. Е. Определить несколько маршрутов в файле routes.rb), но вы можете переопределить метод root_url в ApplicationController, если вы используете именованный путь root в определениях вашего маршрута , Что-то вроде

class ApplicationController

  def root_url(*options)
    if logged_in?
      "/return/something/custom"
    else
      super(*options)
    end
  end

end

Это, однако, звучит действительно плохая идея, так как 1) Вы должны указать на тот же URL и позволить контроллеру обработать запрос (ваши ссылки не должны указывать, куда вас направить), и 2) Это может потенциально сломать другие вещи, которые полагаются на методы root_url и root_path.

Answer 2

К сожалению, маршрутизация Rails может только направлять запросы на разные контроллеры только на основе чего-либо в запросе, что делает данные сеанса для каждого запроса просто недоступными. Ваша текущая реализация, безусловно, самая распространенная стратегия. Я предполагаю что-то вроде этого:

def index
  if logged_in?
     # any logged in logic you need.
  else
     render :file => 'public/home', :layout => false
  end
end

Единственный способ изменить его, чтобы он чувствовал себя менее "непривлекательно", - переместить этот вызов рендеринга в before_filter. Поскольку фильтр будет иметь rendered?, ваше действие вообще не будет вызываться. Конечно, вы также можете выбрать redirect_to другое расположение для аутентифицированных (или неаутентифицированных) запросов в фильтре before, что полностью решит проблему.

Единственное, что вы могли бы сделать, было бы основано на несуществовании файла cookie сеанса.

1. Напишите компонент промежуточного программного обеспечения или приложение Rack (и т. Д.), Которое явно обрабатывает запрос, если нет файла cookie сеанса. Точно так же вы могли бы использовать промежуточное программное обеспечение, чтобы переписать запрос, а затем передать его на прикладной уровень.
2. Используйте стратегию, аналогичную # 1, но делайте это через конфигурацию веб-сервера (Apache или nginx), полностью избегая приложения Rails.

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