我应该为此使用授权 gem 还是简单的 before_filter 方法?

发布于 2024-11-15 19:31:18 字数 713 浏览 3 评论 0原文

我有两种类型的用户:用户和编辑者。我有一个 User 模型,其中包含布尔列 is_editor 来确定用户是否是编辑者。

让我们假设一下。用户 Foobar 决定注册成为编辑。他成功了。从今天起,他就是一名编辑了。有一天,Foobar 意外导航到编辑器注册页面(注册控制器,新操作)。

由于 Foobar 已经是编辑,我应该将他重定向到他的个人资料页面。我应该为此使用授权 gem(例如 Cancan)吗?或者我应该在注册控制器中有一个简单的方法(即 before_filter :check_if_user_is_not_an_editor)来检查用户是否已经是编辑者并重定向?

如果我最终使用康康方法。问题是,我已经有以下内容来检查其他授权。

  rescue_from CanCan::AccessDenied do |exception|
    flash[:alert] = exception.message
    redirect_to root_url
  end

这将呈现一条闪烁警报消息:您未经授权并重定向到根网址。这不是我想要的,因为我需要重定向到 Foobar 的个人资料。

你有什么想法?这是授权任务还是只是所述控制器中的简单重定向?哪种方法更合适?

I have two types of users: user and editor. I have a User model with the boolean column is_editor to determine if a user is an editor.

Let's assume. User Foobar decides to sign up as an editor. He succeeds. From today onwards, he is an editor. One day Foobar accidentally navigates to the editor registration page (registrations controller, new action).

Since Foobar is already an Editor, I should redirect him to his profile page. Should I use an authorization gem (such as Cancan) for this? Or should I have a simple method (i.e. before_filter :check_if_user_is_not_an_editor) in the registrations controller that checks if user is already an editor and redirect?

If I end up using the Cancan approach. The thing is, I already have the following that checks for other authorization.

  rescue_from CanCan::AccessDenied do |exception|
    flash[:alert] = exception.message
    redirect_to root_url
  end

Which will render a flash alert message: You are not authorized and redirect to root url. Which is not what I want, because I need to redirect to Foobar's profile instead.

What are your thoughts? Is this the task of authorization or just a simple redirect in the said controller? Which is the more appropriate approach?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

浪漫之都 2024-11-22 19:31:18

老实说,这看起来很小,所以无论你选择什么,我都不会为你的方法感到难过。就我个人而言,我会选择你的第二个选项(简单重定向)。首先,它看起来更简单,这总是一个优点。如果您使用像 Devise 这样的身份验证解决方案,您可能有一个 current_useruser_signed_in? 帮助程序,您可以在 before 过滤器中轻松使用它们。其次,我并没有真正想到授权所涉及的问题类型。

从某种意义上说,这是一个权限问题(无论如何我猜是语义上的),因为您的应用程序定义了“不允许”的行为。实际上,这是不允许的,但这并不是因为用户没有必要的权限。不允许该行为的原因是因为没有用户应该能够注册为他们已经注册的相同类型的用户 - 也就是说,没有用户类型应该能够执行此类操作,因此当前- 登录用户的权限没有实际意义。看来您的问题应该通过定义应用程序行为来解决 - 而不是用户权限。

就像我看待事物的方式一样,请随意实施您认为最适合的任何解决方案。

Honestly, it seems pretty minor so whatever you choose, I wouldn't feel bad about your approach. Personally, I would go with your second option (simple redirect). First of all, it seems simpler, which is always a plus. If you're using an authentication solution like Devise, you probably have a current_user or user_signed_in? helper that you can use in a before filter quite easily. Secondly, it doesn't really strike me as the type of problem that authorization is concerned with.

In one sense, it is a permissions concern (I guess semantically anyways) since your application defines behavior that is 'not allowed'. Realistically, it's not allowed but not because the user doesn't have necessary permission. The reason the behavior isn't allowed is because no user should be able to register as the same type of user they're already registered as - that is, there are no user types that should be able to do such a thing so the currently-logged in user's permissions are moot. It seems like your problem should be resolved by defining application behavior - not user permissions.

Just the way I see things, feel free to implement whatever solution you feel fits best.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文