Question

我怀疑这是一个比代码更好的最佳实践问题。如果我有一个站点（RoR3和Devise），注册用户可以使用正常的视图集合上传和创建文档到数据库中。当然，用户必须先注册并登录该站点。创建文档后，他们可能希望向未注册该网站的其他人发送链接（并且不会）。

因此，我设想的是一组“只读”的视图，如果您将邀请的人可以查看文档但无法在该视图之外导航，除了主页。 Devise似乎没有我可以看到的非登录访客的概念，我没有找到任何人这样做。

谢谢

Answer 1

Devise为您提供user_signed_in？方法和current_user方法来帮助你处理这类事情。例如，在您的视图中，您可以使用以下内容：

<% if user_signed_in? %>
   <%= current_user.username %>
<% end %>

等

如果您的权限变得更复杂，我建议您使用授权gem来帮助您管理受限制的部分。一些例子是Declarative Authorzation（我个人最喜欢的）和CanCan。

Answer 2

是的，这可能会变得棘手，特别是如果非注册用户可以做一些但不是全部。我们在最近工作的公司中尝试了几种方法来解决这个问题，包括你提到的邀请方面。

由于我们的整个应用程序都围绕着用户，当用户访问该网站时，我们创建了一个User实例。如果用户签名，则用户模型将由数据库记录支持，如果没有，则他们只是虚拟用户，我们使用会话数据来存储半持久状态信息。

在application_controller中，我们将current_user设置为真实用户或只是一个对象，因此它始终可用，并像用户一样嘎嘎叫，特别是包括registered?方法

起初，我们在视图中包含大量内容，if current_user.registered?遍布整个地方。但那很快就变得一团糟。更好的模式（在差异显着的情况下）将创建类似于_sidebar和_sidebar_registered的部分，因此我们可以创建一个方法，给定部分的根名称呈现适当的一个取决于用户状态。

如果邀请用户在邀请内容时对内容的访问权限有限，我们会编写一个由模型支持的邀请模块。邀请者可以从系统发送电子邮件，或生成带有嵌入式令牌的URL。我们将令牌存储在一个表中，以便我们知道谁邀请了谁，这在我们的案例中是必要的 - 查找令牌是验证所需的全部内容。一旦用户进行了排序认证，我们就将状态存储在会话中，并且用户（invited?）上的方法会告诉我们用户是否有权访问。

一般情况下，只有注册用户才能进行某些控制器操作（例如编辑/删除），我们只需在控制器中使用before_filters来控制访问。事情的主要原因是事情变得混乱。

当我们开始获得不同级别的用户授权时，我们确实看过CanCan。但我可以告诉你，除非你仔细分离谁可以看到并做什么，否则这可以迅速成为相当粗糙的代码。

在同一站点上混合安全用户和访问者

2 个答案: