应用程序逻辑(身份验证/授权的适当位置)

发布于 2024-10-08 05:42:55 字数 732 浏览 4 评论 0原文

我正在使用 MVC 3 (RC2) 开发一个类似 CMS 的应用程序,此时我正处于十字路口。我无法说服自己我提出的方法是否合适。我想这是因为我知道我正在试图走捷径,这会让我在以后付出沉重的代价。

我将直接描述我的问题:

1)我有一个资源(我们称之为 A),必须使其可编辑。

2) 我实现了一个自定义权限系统,它有 2 个(许多)权限:

  • 可以编辑自己的资源
  • 可以编辑其他资源

3) 如果资源 A 的创建者具有“可以编辑自己的资源”权限,则可以自由编辑它。

4) 单独的用户只能在拥有“可以编辑其他资源”权限的情况下编辑 A

现在已经描述了需求,让我告诉您到目前为止我的方法:

1) 我有一个名为“ResourceController”的控制器

2) 我有一个名为“编辑”的操作

3) 该操作有一个属性: [CustomerAuthorize(Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true)]

4) 我有一个负责域验证的服务类。

因此,如果用户具有“可以编辑自己的资源”或“可以编辑其他资源”权限,则他们可以调用操作方法。

我如何决定(以及应该在哪里做出这个决定)用户是否拥有正确的权限(取决于他们是否拥有资源?)它应该在控制器操作中,在资源服务类中,在单独的服务等级?

等待听到不同的意见...

I am developing a CMS like application using MVC 3 (RC2) and I am in crossroads at this point. I am unable to convince myself if my proposed approach is appropriate or not. I guess it is because I am aware that I am trying to cut some corners which will cost me heavily later down the line.

I will get right down to describing my problem:

1) I have a resource (lets call it A) which has to be made editable.

2) I have a custom permission system implemented which has 2 (of many) permissions:

  • Can Edit Own Resource
  • Can Edit Other Resource

3) Creator of resource A is free to edit it if they have 'Can Edit Own Resource' permission.

4) A separate user can only edit A if they have permission 'Can Edit Other Resource'

Now that the requirement is described, let me tell you my approach so far:

1) I have a controller called 'ResourceController'

2) I have a action called 'Edit'

3) The action has a attribute on it: [CustomerAuthorize(Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true)]

4) I have a service class which takes care of domain validation.

So a user get call the action method if they have either the 'Can Edit Own Resource' or 'Can Edit Other Resource' permission.

How do I decide (and where should this decision be made) on whether the user has the right permission or not (depending on whether they own the resource?) Should it be in the controller action, in the resource service class, in a separate service class?

Waiting to hear different views...

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

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

发布评论

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

评论(2

情丝乱 2024-10-15 05:42:55

由于 MVC 的性质,您将需要在多个点进行身份验证检查。

其一,您需要能够在 UI 上显示视觉提示(即显示或不显示编辑按钮),因此逻辑必须可供您的视图使用。

当然,这仅用于 UI 目的。您还需要对控制器操作进行身份验证/授权,以防万一有人绕过您的 UI 来访问它。

最后,验证和授权操作的最安全位置是在执行操作之前。例如,如果您有一个处理程序,我会在那里放置一些授权逻辑。您希望确保没有人可以通过从其他地方调用该服务而不知道该服务存在限制来绕过您的安全逻辑。这也有助于使安全选项更加精细。

Because of the nature of MVC, you will want to have your authentication checks at a variety of points.

For one, you'll need to be able to display visual cues on the UI (i.e. show the edit button or not show it), so the logic will have to be made available to your Views.

Of course, that's only for UI purposes. You'll want authentication/authorization on your controller actions as well, just in case someone goes around your UI to access it.

Finally, the most secure place to authenticate and authorize an action is right before you perform it. If you have a handler, for example, I would place some authorization logic there. You want to make sure that no one can write around your security logic by calling the service from somewhere else, and not knowing that there were restrictions on that service. This helps make the security options more granular as well.

四叶草在未来唯美盛开 2024-10-15 05:42:55

处理它的一种方法是有 2 个操作,而不是只有“编辑”,您有“EditOwnResource”和“EditOtherResource”。然后,您可以对其中每一个设置一个权限。

然后,如果您使用 MVVM 模式,您可以将这些操作的可用性绑定到它是 ownResource 还是 otherResource。这些值的设置是在视图模型中完成的。

One way to approach it is to have 2 actions, instead only "Edit", you have "EditOwnResource" and "EditOtherResource". You can then place a single permission on each of these.

Then if you are using the MVVM pattern you can bind the availability of these actions to wether it is an ownResource or otherResource. The setting of these values is done in the view model.

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