使用Devise和STI设计具有多种用户类型的Rails应用程序

Question

我对Rails相对较新,到目前为止只编写了一个应用程序.我在该应用程序中使用Devise进行身份验证.现在我要进入第二个,因为我有很多用户类型,而不是我的第一个应用程序中的单个用户类型,所以我必须更多地考虑身份验证.

我一直在研究这些问题,以便当我将代码放到金属(或云)时,我可以在设计时考虑到清晰的设计.

到目前为止,我发现此帖最有用:

• 设计和多个"用户"模型

背景

我正在创建一个在线市场,客户可以从供应商那里订购东西.

我打算创建以下用户类型:

• 客户:访问市场并订购东西
• 提供者:在市场中创建东西并处理订单
• 员工:适用于提供商
• 超级管理员:管理网站
• 管理员:管理由超级管理员委派的部分网站

以下字段是我在上述三种用户类型之间共享的标识:

• 电子邮件地址(用作登录ID)
• 手机号码

然后,每个用户类型具有不同的字段(每个4到6个字段).

客户和提供商将自行注册.员工和管理员将分别由提供商和超级管理员注册.

员工将与提供商相关联.我不认为员工与多个提供商有关联.

我也没有预见到具有多个角色的用户的需要.

我的计划

在对选项进行一些研究之后,我决定了以下内容:

我将创建三种不同的用户模型:

• 顾客
• 提供商
• 超级管理员

在我看来,这些都是真正不同的用户,他们将与应用程序的不同部分进行交互,因此感觉很干净.根据我的研究,这种方法还允许我完全自定义每个用户类别的注册过程.例如,我可以允许客户注册他们的Facebook帐户(使用OmniAuth),但不能将此选项扩展到我的提供商.当然,超级管理员不会:可以注册.据我所知,每个用户都有单独的登录页面,这对我来说不是问题(实际上是可取的).

拥有不同的模型,特别是对于Admin,我可以稍后轻松地重构,以防我需要实现其他角色.

问题

上面的设计是否像我能做到的那么简单？没有任何战斗计划能够与敌人保持联系.但我希望Rails是我的朋友:)所以在纸面上,我的计划对我来说似乎很简单.有什么我想念的东西会使它的实现比纸上的更复杂吗？

此外,即使我已经设计了上述计划(双关语),我也愿意接受其他建议.例如,有什么理由我想为所有模型做STI(有一个用户模型,我的所有其他模型都继承了这个模型)？

谢谢阅读!

Answer 1

Rails Cast 有一个非常可靠的解决方案，至少可以处理您的解决方案带来的一些复杂性。Bates 向用户模型引入了角色属性，该属性封装了用户拥有的角色（或多个角色）。他将其与 gem CanCan 结合起来，以指定哪个角色可以执行哪些操作。

看看这个http://railscasts.com/episodes/192-authorization-with-cancan?view=asciicast

首先看看他如何设置和获取 Roles 属性，然后看看他如何将其与 CanCan 耦合。