在Rails中确定并保留多租户Web应用程序中的当前租户

时间:2012-06-29 00:59:19

标签: ruby-on-rails multi-tenant

我正在考虑一个多租户应用程序 - 共享数据库,共享架构。租户标识符(租户密钥)将每一行与正确的租户相关联。

我不确定如何将tenant_id加载到某种全局范围。这怎么会发生?我假设我将解析域,然后根据域查找tenant_id。

我的问题:

  1. 在rails应用程序中进行查找的位置?在初始化程序中?有没有更好的观点呢?
  2. 一旦我确定了tenant_id,坚持它的最佳方法是什么 - 一个简单的session_id?

1 个答案:

答案 0 :(得分:4)

我为此功能的控制器使用了前置过滤器。

您还可以对控制器类进行子类化以清除控制器中的重复代码。

请注意,需要根据每个用户对访问给定租户的信息进行身份验证。您需要确定给定用户是否可以访问多个租户。例如,用户“joe”是否可以访问租户1和2?或者乔是否需要每个租户登录?

登录授权应控制对租户信息的访问。不要依赖域名授予授权。

Re:在哪里坚持tenant_id?存储在会话中。如果对会话的访问很昂贵(存储在DBMS中),那么在控制器启动期间将内存中的副本作为实例变量。关于如何经常存储user_ids的Google。

您还应确定用户是否/何时想要访问其他租户的用户体验。

已添加要查看在用户登录之前要加载的欢迎屏幕,查看子域名是一个不错的选择。要查看传入请求使用的子域,请解析request.fullpath() Docs.在控制器过滤器中执行此操作。

由于授权来自user_id,请记得测试joe在tenant1.app.com上登录但只能访问tenant2.app.com的案例

奖励回答寻找一种模板系统,让您的客户可以完全控制租户的用户界面?查看Liquid templates。我非常成功地使用它们使我的客户能够以安全的方式完全控制他们的外观和感觉。

在评论中添加其他问题

  • 请参阅超级用户以配置Web服务器。配置是特定于Web服务器的。
  • 如果您希望欢迎屏幕不是通用的,那么您必须从请求网址知道如何自定义它。特定于租户的子域是最好的。如果没有子域,则显示通用欢迎 - 当用户登录时,您可以确定租户以及如何自定义。

重新帮助 - 如果您指的是视图助手,那么我不建议将其作为确定租户的主要位置。使@user@tenant成为您查找过一次的轻量级模型,然后在对同一会话的其他请求期间从会话中检索。模型将由控制器使用,并可能传递给模型。 View层也可以看到它们并在必要时使用它们。

如果不同租户的UI看起来/看起来完全不同,那么除了视图外,还要添加“租户显示”图层。例如,让视图收集实例变量,找到正确的Liquid模板,然后通过模板表达视图。

您不希望视图计算“如果tenant_a则x其他y”