1

マルチテナント アプリケーション (共有データベース、共有スキーマ) を検討しています。テナント識別子 (テナント キー) は、すべての行を適切なテナントに関連付けます。

私が確信していないのは、tenant_id をある種のグローバル スコープにロードする方法です。これはどのように起こるべきですか？ドメインを解析し、ドメインに基づいて tenant_id を検索するとします。

私の質問:

  1. Railsアプリケーションでは、ルックアップはどこで行われますか? イニシャライザで？これを行うより良い点はありますか？
  2. tenant_id を特定したら、それを維持するための最良の方法は何ですか?単純な session_id ですか?
4

1 に答える 1

4

この関数のコントローラーにはbeforeフィルターを使用します。

コントローラクラスをサブクラス化して、コントローラ内の重複コードをドライアウトすることもできます。

特定のテナントの情報へのアクセスは、ユーザーごとに認証される必要があることに注意してください。特定のユーザーが複数のテナントにアクセスできるかどうかを決定する必要があります。たとえば、ユーザー「joe」はテナント1と2にアクセスできる必要がありますか？または、ジョーはテナントごとのログインが必要ですか？

ログインの承認により、テナント情報へのアクセスを制御する必要があります。承認を付与するためにドメイン名に依存しないでください。

Re：tenant_idをどこに永続化するのですか？セッションに保存します。セッションへのアクセスにコストがかかる（DBMSに格納されている）場合は、コントローラーの起動時にインスタンス変数としてメモリ内コピーを作成します。user_idsがどのように保存されるかについてのGoogle。

また、ユーザーが別のテナントにアクセスするかどうか/いつアクセスするかについてのユーザーエクスペリエンスを決定する必要があります。

追加ユーザーがログインする前にロードするウェルカム画面を確認するには、サブドメイン名を確認することをお勧めします。request.fullpath() 着信リクエストが使用したサブドメインを確認するには、ドキュメントを解析します。コントローラフィルターでこれを行います。

承認はuser_idから行われるため、joeがtenant1.app.comにログインし、tenant2.app.comにしかアクセスできない場合をテストすることを忘れないでください。

ボーナスアンサー顧客がテナンシーのユーザーインターフェイスを完全に制御できるようにするテンプレートシステムをお探しですか？Liquidテンプレートを確認してください。私は、顧客が安全な方法でルックアンドフィールを完全に制御できるようにするためにそれらを使用することに非常に成功しました。

コメントで追加の質問を再

  • Webサーバーの構成については、スーパーユーザーを参照してください。構成はWebサーバー固有です。
  • ウェルカム画面を一般的なものにしたくない場合は、リクエストURLからカスタマイズ方法を知っておく必要があります。テナント固有のサブドメインが最適です。サブドメインがない場合は、一般的なウェルカムを表示します。ユーザーがログインしたときに、テナントとカスタマイズ方法を決定できます。

リヘルパー-ビューヘルパーを意味する場合、テナントが決定される主要な場所としてはお勧めしません。を作成し@user、@tenant一度調べて、同じセッションの追加リクエスト中にセッションから取得する軽量モデルにします。モデルはコントローラーによって使用され、おそらくモデルに渡されます。ビューレイヤーはそれらを表示し、必要に応じて使用することもできます。

テナントごとにUIの外観が完全に異なる場合は、ビューに加えて「テナント表示」レイヤーを追加します。たとえば、ビューにインスタンス変数を収集させ、適切なLiquidテンプレートを見つけて、テンプレートを介してビューを表現します。

ビューが「iftenant_athenxelsey」を計算することは望ましくありません。

于 2012-06-29T02:44:02.900 に答える