0

Rails 3 / 4 からサーバーの完全な Web サイトへのユーザー ログイン (ユーザー中心のルーティング) に基づくユーザー ルートの制約は可能ですか? アプリのサブディレクトリにさまざまな静的 Web サイトを配置し、メイン ルート (ログインによって保護) の下でユーザーがアクセスできるようにすることを大まかに考えていました。

ユーザーがログインしていない場合は、単純なログイン マスクを使用してユーザーを識別します (devise など)。ミドルマンで生成された静的ページのステージング展開を簡素化することを考えていました。サブドメインや ftp アップロードなどを作成する代わりに、Rails アプリにデプロイするための単純な capistrano タスクを用意する方がはるかに優れています。

静的ページを / の下にマウントする理由は、ほとんどの静的サイト ジェネレーターがページが / の下にあることを想定しており、アセット内の絶対/相対パスに関する問題を回避したいからです。

もう少し詳しく言うと：

ケース 1)ユーザーがログインしていない -> どのルートも認証を要求する

ケース 2)ユーザーがログインし、静的コンテンツが /app/sites/site1 (「/」にマウント) から提供される

ケース 3)別のユーザーがログインしている場合、静的コンテンツは /app/sites/site2 (「/」にマウント) から提供されます。

提供されるサイトは、ユーザーのプロファイルによって異なります。

4

1 に答える 1

0

私自身の質問に答えるには：はい、可能です。

私の場合、Rails はやり過ぎではありません。Rails ベースのプロジェクト管理システムとシームレスに統合しています。ユーザー セッションに基づいて別のパブリック URL を使用して、 Sinatra -App を Web サーバーとしてマウントしています。セッションは一意のトークンを介して生成されるため、ユーザーはさまざまな静的プロジェクトを次々と表示できます。

ルート.rb:

constraints(:subdomain => /preview/) do
    mount SinatraWrapper => "/"
end

注: ここでは、サブドメインをチェックするために制約を使用しています。すべての静的プレビューは、異なるサブドメインの下の同じアプリにリダイレクトされます。

シナトララッパー:

# a super-trivial Sinatra-based webserver
# for static content
require 'sinatra/base'

class SinatraWrapper < Sinatra::Base
  before '/*' do
    SinatraWrapper.set_site(session[:site])
  end

  def self.set_site(site)
    rootPath = File.expand_path("#{Rails.root}/sites/#{site}/")
    set :public_folder, "#{rootPath}/current/build/"
  end

  configure do
    set :static, true
    set :static_cache_control, [:public, :no_store, :no_cache, :must_revalidate, :max_age => 0, :expires => "Fri, 01 Jan 1990 00:00:00 GMT"]
  end

  set_site("default")

  # route to starting page (index.html)
  get "/" do
    redirect "/index.html"
  end

  # route to custom error page (404.html)
  not_found do
    redirect "/404.html"
  end

end

注: カピストラーノ経由で静的プロジェクトから更新を Rails アプリにデプロイしています。ビルドはMiddlemanを介してリモートで実行されます(ここでは他の静的サイト ジェネレーターを使用できます)。別のインスタンスは、「プレビュー」ブランチで git リポジトリの更新をチェックし、そこでテストを実行します。すべてのテストに合格すると、ビルドが実行され、自動的にデプロイされます。

2 つの異なるサブドメインに対して異なる動作を使用するが、同じセッションを使用するというトリッキーなビットがあります。

# static_pages_controller.rb:

def preview

    if request.subdomain == "preview" or Rails.env.development? # local dev: no subdomains
      @static_page = StaticPage.find(params[:id])
      session[:site] = @static_page.slug || "default" # using a sha-slug for every static project
      redirect_to "/" # redirect to root. we have a valid session now.
    else
      # we are NOT on the preview subdomain, so we need to redirect to proper subdomain
      @project = Project.find(params[:project_id])
      @static_page = StaticPage.find(params[:id])
      redirect_to preview_url(project_id: @project.id, id: @static_page.id, token: @static_page.slug).sub("plattform", "preview")
    end
end

注: 私は多くの静的ページを含むプロジェクトを持っています。プラットフォームからのすべての静的ページのプレビュー アクションがあります。プラットフォームからのリンクでプレビュー アクションをヒットすると、プレビュー サブドメインにリダイレクトされ、セッションが設定されます。私たちの認証により、

  • 認証トークン (SHA-Slugs) を含む匿名リンクを顧客に送信する
  • データベース経由で認証する

私たちはこのシステムを半年間使用していますが、とても満足しています! お客様はすぐにプレビューを見ることができます。ページをリロードするたびに新しいコンテンツが読み込まれるように、キャッシュ ヘッダーを正しく設定する必要があることを除いて、これまでのところ重大な問題は発生していません。これによりエクスペリエンスが遅くなりますが、これはプレビューであると常に主張できます. 正直なところ、ほとんどの顧客はロード時間を認識していません。

とにかく、キャッシュを「クラッシュ」させるための実装が完璧な解決策であるかどうかは 100% 確信が持てません。どんなヒントでも大歓迎です。新しいコンテンツが表示されるまでページを数回リロードする必要がある Chrome と Safari (非常にまれ) でのみ問題が発生します。

もう 1 つの興味深い質問は、セキュリティです。比較的安全だと思います。しかし、私はセキュリティの専門家ではありません。懸念事項はありますか？

このプラットフォームは社内でのみ使用します。非常に丁寧なエラー処理を行っておりますので商品の間違いはございません。

于 2014-07-30T10:12:30.863 に答える