ruby-on-rails - 如何在不使用子域的情况下设置 Multi-Tenancy Rails 应用程序？

Question

我正在尝试为员工创建一个带有后端的 SAAS 电子商务工具，该工具还允许客户在前端拥有帐户和结帐。我正在苦苦思索如何设计它，以便公司、帐户所有者、员工和客户都被隔离到每个公司，同时还根据他们的角色进行适当的限制。

到目前为止，我所读到的大多数 Rails 解决方案都使用带有子域的 Multi-Tenancy 模式，例如 Apartment gem , 隔离帐户。但让您的网站使用一个大型应用程序和数据库似乎更简单。例如，Basecamp 最近通过 Basecamp3 转向了这种方法。 .较新的应用程序似乎是以这种方式构建的。

而且，管理功能和客户帐户/前端商店是否应该完全是单独的应用程序，或者您可以使用“majestic monolith”来做到这一点？一个大的应用程序和数据库虽然很大，但对我来说似乎更直接。

我找到了 this blog post这解释了如何用 Pundit 做这样的事情，但我仍然无法了解如何在同一个应用程序中与帐户所有者、员工和客户一起工作。

以下是我的应用程序的基本需求:

用户角色

帐户所有者(创建公司帐户并拥有对其公司数据的完全访问权限)

员工(受邀加入公司，但无权访问公司的某些数据，例如帐单信息)

客户(可以注册网站并查看产品，将它们添加到购物车，但不能访问任何员工或帐户所有者功能。)

所有用户(无论角色如何)都属于一个公司，不能访问其他公司的数据。 (因此提供了在同一个应用程序上运行不同商店的能力，这是将其作为 SAAS 应用程序运行所必需的。)

帐户所有者和员工可以 CRUD 产品，但不能是客户。

一个很好的类比是 Shopify 的管理区域和客户帐户目前如何为店主工作，但与 Shopify 不同的是，它不需要使用子域。

潜在模型和关联

Company
has_many :users, dependent: :destroy
has_many :products, dependent: :destroy

User
belongs_to :company

Product
belongs_to :company

授权

使用 Pundit 限制基于用户角色的 Controller 操作，然后确保通过模型关联隔离数据是否有效？

注册流程

我对如何处理不同用户角色的范围以及“员工邀请”和“客户”注册可以适合注册流程的位置有些模糊。

这种方法行得通吗？

为“帐户所有者注册”、“员工注册”、“客户注册”创建单独的 Controller ，然后将我的注册表单嵌入到这些 View 中。 (使用 Clearance 进行身份验证并希望尽可能保留它，但只需根据需要增加它)。

帐户所有者注册:因此，如果有人通过新帐户注册 Controller (带有嵌入式身份验证表单)注册，他们还将创建一个公司。

员工邀请:帐户所有者可以通过输入姓名和电子邮件地址来创建新的员工用户。这将创建一个具有“员工”角色的新用户(因此不能成为另一个帐户的帐户所有者)。新的“员工”用户会收到一封邀请电子邮件，基本上是密码重置电子邮件，邀请他们通过创建密码来接受邀请。

客户注册:如果有人通过“客户注册” Controller 注册，他们将自动获得用户角色“客户”。在这种情况下不确定如何设置公司 ID。 (将 company_id 作为隐藏输入传递给客户注册表单？)

有没有更好的方法来设计我缺少的这种类型的应用程序？我在正确的 rails 上吗？我没有构建这样的东西的经验，所以任何线索都会非常有帮助。

似乎较新的应用程序遵循这种 Multi-Tenancy 模式而不是子域模式。

Answer 1

你打开 simple e-commerce site但是您提出的问题表明您正在寻找更复杂的东西:) 您走在正确的 rails 上。

act_as_tenant gem 值得一看。我们现在使用它，它有助于确保您的查询都在适当的范围内。

如果您需要执行角色，我也会查看并评估 rolify(但也不排除您的用户使用 bool 标志)。

我不排除设计，但清除很受欢迎。

根据工作量的不同，使用子域可能是未实现的工作，除非您需要出于虚荣目的而实际使用子域(my.example.com 与 example.com/my)，否则您可以在没有它的情况下进行 Multi-Tenancy 。

如果不同角色的访问权限变化很大，我会考虑为不同角色设置单独的 Controller 和命名空间；您还可以使用 Pundit 将它们组合成单个 Controller (但这可能很笨拙)。您仍然希望使用 Pundit，但是，Pundit 可以执行诸如限定用户应该查看的记录范围之类的操作。

您走在正确的 rails 上并提出了正确的问题，但所有这些问题的答案将取决于其他问题(您现在可能甚至无法回答)。

我有一个项目，我正在做你提到的事情(专家限制数据，acts_as_tenant 限制数据)，但随着它的发展，某些模式出现，导致我走上不同的道路。例如，命名空间管理，而不是在同一个 Controller 内进行管理检查；因为如果你重写一个 API，你最终会试图让同一个端点做不同的事情，在我看来，将命名空间后面的 2 个端点分开并记录实际行为会更清晰。