如何创建不同权限的页面意见

发布于 2024-10-20 10:42:32 字数 1230 浏览 2 评论 0原文

我需要为不同类型的用户创建不同的页面视图。 我已经在这里问过:如何创建具有不同权限视图的页面< /a>

尽管阿尔迪尔的答案有效,但对我来说这似乎不是最好的解决方案。我会解释原因。

我会尝试非常详细地解释我需要什么,希望你们中的一些人能够帮助我:D

我需要展示不同的观点,但不仅如此。每个用户都可以访问页面的不同部分。

我举一个例子:

想象一个具有这种结构的页面“X”

Field A
Field B
Field C
Field D

当来自组G1的用户U1访问页面X时,系统会检查页面 X 上该组权限的数据库。用户U1可以看到字段A字段B,但只能编辑字段A

设置为无组的用户 U2 访问页面 X。系统检查他在X页面上的权限。用户U2可以查看和编辑所有字段。

当组 G2 中的用户 U3 访问页面 X 时,系统会在数据库中检查该组对页面 X 的权限。用户U3可以看到字段C字段D,但无法编辑任何内容。

我希望它很容易理解...

我找不到一种方法来做到这一点,而不是用大量有关特定用户权限的数据填充 ViewData 。在我的示例中,只有 4 个字段,但在我当前的项目中,没有少于 20 个字段的屏幕。所以我想你可以看到这是多么丑陋和低效。

正如我所说,这个想法类似于社交网络(facebook 示例< /a>)。当用户访问 UserX 的页面时,只能看到 UserX 允许他看到的内容。

我真的很感谢任何帮助。

此致。

I need to create different page views for different types of users.
I already asked that here: How to create pages with different permissions' views

And even though Aldeel's answer works, it does not seem the best solution for me. I'll explain why.

I'll try to explain what I need very detailed and hopefuly some of you will be able to help me out :D

I need to show different views but it's not only like that. Each user can have access to different parts of the page.

I'll give an example:

Imagine a page 'X' with this structure

Field A
Field B
Field C
Field D

When user U1 from group G1 visit page X the system checks the DB for that group's permission on page X. User U1 can see Field A and Field B, but only edit Field A.

User U2 that is set to no group visits page X. The system checks for his permissions on page X. User U2 can see and edit all fields.

When user U3 from group G2 visit page X the system checks the DB for that group's permission on page X. User U3 can see Field C and Field D, but can not edit any.

I hope it's easy to understand...

I coudn't find a way to do that instead of filling ViewData with lots of data about that specific user's permission. In my example there are only 4 fields, but in my current project I have no screen with less than 20 fields. So I guess you can see how ugly and not productive that is.

The idea is similar to a social network, as I said (facebook example). When a user visiting UserX's page can only see what UserX has allowed him to.

I really appreciate any help.

Best regards.

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

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

发布评论

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

评论(2

五里雾 2024-10-27 10:42:32

为了做你想做的事情,你不应该控制你的视图 - 你实际上必须保护你的控制器 - 而不是视图。您可以通过控制器属性来做到这一点。与此类似:

[Authorize]
public class MyController {
}

通过这样做,您可以保护整个控制器。如果用户未经身份验证,该控制器中的每个操作都不会响应(具体来说,他们将收到 401 响应)。您可以通过授权单个用户或单个角色来扩展此功能,如下例所示:

[Authorize(Users="eestein,JasCav")
public class MyController {
}

[Authorize(Roles="Administrator")]
public class MyController {
}

在您的情况下,您可能不希望整个控制器都具有授权。嗯,非常出色的是,ASP.NET MVC 提供了身份验证的操作级别控制。因此,您可以这样做:

public class MyController {

    public ActionResult Index() { }

    [Authorize(Roles="Administrator")]
    public ActionResult Admin() { }

}

使用这个想法,您可以控制用户在页面上看到的内容。您将希望从操作中返回部分页面,以便您可以加载页面的各个方面。例如,您可能有一个显示一些正常数据和一些秘密数据的视图。通过正常页面即可返回正常数据。秘密数据应作为页面内的部分视图返回。但是,如果发生 401,您可以处理它并且不显示任何内容。

做起来相当简单。 .NET 团队在设置方面做得很好,您不必单独检查控制器内的权限。我希望这可以帮助您入门。在线搜索有关如何使用授权属性的更多信息。

更新
如果您有控制这些权限的页面管理员,则您必须明智地设置授权属性。这就是“角色”非常重要的地方(根据我上面的例子)。例如,如果管理员说“我要将 John Doe 添加到 SpecialUser 角色”,那么 John Doe 用户将能够访问该角色设置为 SpecialUser 的所有操作(如果确实如此)您系统上的角色)。

显然,您必须为管理员提供某种能够执行此操作的方法,而授权属性可以完美地做到这一点。要查看谁拥有某个页面的权限,您必须查询数据库以找出谁属于哪个角色。这是考虑设置的一种方法:

  • 您控制操作的角色。
  • 您的管理员控制谁被授予这些角色。
  • 您可以随时检查(通过简单的查询)了解谁被分配了哪个角色。然后,您可以(通过您对操作角色的了解)查看谁看到了网站的哪个部分。

我希望这能澄清(我希望我足够理解你的问题)。我认为你想做的事情是可能的。

更新2
是的,这确实假设您的控制器上有静态组,并且必须以编程方式添加任何新组。我很想知道什么样的用例需要动态创建不同的权限类型 - 这似乎很容易被滥用。无论如何,我对此没有解决方案。

至于部分视图是如何工作的...它是这样的...

public class ProductController : Controller
{
    //
    // GET: /Index/
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult Partial1()
    {
       return PartialView();
    }

    [Authorize]
    public ActionResult Partial2()
    {
       return PartialView();
    }
}

在您的 Index.aspx 文件中,您将看到类似这样的内容:

<%= Html.RenderAction("Partial1") %>
<%= Html.RenderAction("Partial2") %>

如果用户未获得授权,您可以处理第二个 RenderAction 所以视图永远不会显示。 (您可以在控制器中进行检查。)

希望能够澄清问题!我正在逃亡,所以现在无法进一步展开。

To do what you are looking to do, you shouldn't control your views - you actually have to secure your controllers - not the views. You can do this via controller attributes. Something similar to this:

[Authorize]
public class MyController {
}

By doing this, you secure the entire controller. Every action within that controller will not respond if the user is not authenticated (specifically, they will receive a 401 response). You can extend this by authorizing individual users or individual roles as shown in the examples below:

[Authorize(Users="eestein,JasCav")
public class MyController {
}

[Authorize(Roles="Administrator")]
public class MyController {
}

In your case, you may not want to have an entire controller with authorization on it. Well, excellently enough, ASP.NET MVC provides action-level control of authentication. So, you can do this:

public class MyController {

    public ActionResult Index() { }

    [Authorize(Roles="Administrator")]
    public ActionResult Admin() { }

}

Using this idea, this is where you can control what a user sees on a page. You are going to want to return partial pages from your actions so that you can load various aspects of the page. For example, you may have a view that shows some normal data and some secret data. The normal data can be returned via the normal page. The secret data should be returned as a partial view within the page. However, if a 401 occurs, you can handle it and just not show anything.

It is fairly straightforward to do. The .NET team did a great job of setting this up and you don't have to individually check permissions within your controller. I hope this helps get you started. Do a search online for more information about how to use the Authorization attribute.

Update
In the case where you have an administrator of a page who is controlling those permissions, you have to be smart about how you setup your Authorize attribute. This is where "Roles" are very important (per my examples above). For example, if the administrator says, "I'm going to add John Doe to an SpecialUser role," then John Doe user is going to be able to access all the actions in which the role is set to SpecialUser (if that is indeed a role on your system).

Obviously, you're going to have to give administrators some way of being able to do this, and the Authorize attribute does this perfectly. To see who has permissions on a page, you will have to query the database to find out who is part of what role. Here is a way to think about the setup:

  • You control the Roles of the actions.
  • Your administrators control who gets granted those roles.
  • You can always check (via a simple query) to see who is assigned to what role. You can then (via your knowledge of the actions roles) see who sees what part of the site.

I hope this clarifies (and I hope I understood your problem well enough). I think what you are trying to do is possible.

Update 2
Yes, this does assume you have static groups on your controllers and any new group would have to be programmatically added. I'd be curious to know what kind of use case requires different permissions types to created on the fly - that seems like it would be open to abuse. In any case, I don't have a solution for this.

As for how partial views work...it's something like this...

public class ProductController : Controller
{
    //
    // GET: /Index/
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult Partial1()
    {
       return PartialView();
    }

    [Authorize]
    public ActionResult Partial2()
    {
       return PartialView();
    }
}

Inside your Index.aspx file, you'll have something like this:

<%= Html.RenderAction("Partial1") %>
<%= Html.RenderAction("Partial2") %>

If the user is not authorized you can handle the second RenderAction so the view never even shows. (You can check that within your controller.)

Hope that clarifies things! I'm on the run, so I can't expand on it more now.

最佳男配角 2024-10-27 10:42:32

我会推荐“附加”安全性;用户的权限及其任何组的权限加在一起给出了允许他执行的一系列操作。如果他没有明确的许可去做需要许可的事情,他就不能做。在您的情况下,在用户 U1 和组 G1 之间,授予用户足够的权限来查看字段 A 和字段 B,以及编辑字段 A。由于用户自己或通过其组,没有明确授予以下权限:编辑字段 B 或查看或编辑字段 C 和 D,他没有这些权限。

我将通过在代码隐藏中放置一个方法来实现这种类型的权限,该方法将接受代表用户及其权限的对象,并将询问这些权限以确定字段的可见性。所有字段一开始都应该是不可见的,此方法将使它们可见和/或可编辑。

需要注意的事项:

  • 确保您使用 .NET 服务器端工具来显示/隐藏字段。如果某个字段的 Visible 属性在服务器端设置为 false,则呈现的页面甚至不会在 HTML 中包含该字段。相比之下,添加样式或使用 JavaScript 来隐藏属性会将它们保留在 DOM 和 HTML 中,因此人们可以“查看源代码”来查看以这种方式隐藏的字段。
  • 切勿使用客户端代码来实现安全性。 JavaScript、ActiveX 控件等可以被拒绝、禁用和/或操纵。显示数据的客户端代码还要求数据位于页面源中的某个位置,这意味着可以通过查看页面源轻松找到它。
  • 出于同样的原因,不要相信不可编辑字段的数据不会更改。 HTML 和客户端代码可以使用 FireBug 等工具轻松更改。
  • 如果您从所有不可见/禁用的内容开始并使它们可见/启用,那么您的代码将比从广泛开放的访问开始并隐藏内容更安全。如果你忘记隐藏一些新的东西,客户会突然看到一个他们不应该接触的新领域。如果您忘记添加代码以根据权限显示新字段,您仍然需要修复它,但利用不存在的字段要困难得多或不可能。

I would recommend "additive" security; a User's permissions, and that of any of his Groups, total together to give a series of things he is allowed to do. If he doesn't have explicit permission to do something for which permission is required, he is not allowed to do it. In your case, between User U1 and Group G1, there are sufficient permissions granted for the user to see Field A and Field B, and to edit Field A. As the user, either themselves or through their group, was not explicitly granted permission to edit Field B or to view OR edit Fields C and D, he does not have those permissions.

I would implement this type of permission by putting a method in the codebehind that will accept an object representing the user and their permissions, and will interrogate those permissions to determine visibility of fields. All fields should start out as invisible, and this method will make them visible and/or editable.

Things to be aware of:

  • Make sure you are using the .NET server-side tools to show/hide fields. If a field's Visible property is set to false at the server side, the rendered page will not even include that field in the HTML. By contrast, adding a style or using JavaScript to obscure properties keeps them in the DOM, and in the HTML, so a person can "view source" to look at fields hidden this way.
  • NEVER use client-side code to implement security. JavaScript, ActiveX controls, etc can be refused, disabled and/or manipulated. Client-side code to show data also requires that data to live somewhere in the source of the page, meaning it can be found very easily by viewing the page source.
  • By the same token, do not trust that a non-editable field will not have its data changed. HTML, and client-side code, can be changed very easily with tools like FireBug.
  • Your code will be more secure if you start with everything invisible/disabled and make them visible/enabled, than if you start with wide open access and hide things. If you forget to hide something new, all of a sudden clients see a new field they shouldn't touch. If you forget to add code to show a new field based on permissions, you still have to fix it but it's much harder or impossible to exploit a field that doesn't exist.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文