0

我目前正在构建一个 ASP.NET MVC Web 应用程序。我的站点安全性（当前）构建在我扩展的 System.Web.Security Membership 模型的扩展之上：

  • 授权属性
  • 会员提供者
  • 角色提供者

这对安全机制来说已经足够了——尽管它使很多事情变得复杂，我本可以更简单地完成。但是，它已经完成了，这是一次非常有用的学习经历。尽管稍后，我仍可能将其全部删除并用更特定于该站点的模型替换它 - 我想将我的所有用户配置文件信息保存在一个单独的表中，并专门为该站点建立索引和构建。

现在我已经开始开发用户个人资料了。我需要存储比基本用户登录系统更多的用户信息。我已经检查了 ProfileProvider，它似乎是一个完全不同的蠕虫罐头。我喜欢它足够灵活，我可以直接从 web.config 配置用户配置文件，而无需重新构建我的对象，而 ProfileProvider 会处理其余部分。不过，让我感到恐惧的是 PITA 会导致在我的数据库上运行查询或报告。这个事实可能会影响我对 ProfileProvider 的判断。ProfileProvider 甚至是用于此目的的正确模型吗？

我应该走与定制现有系统或定制构建自己的系统相同的道路吗？

一方面，ProfileProvider 的自定义可能是一种有用的学习体验，但另一方面，我可以看到这迅速成为报告和查询的噩梦。但是我自己的编码将使查询/报告变得非常简单，但我不会学得更少。

如果有人对 ProfileProvider 模型的使用或定制有任何经验（如果这确实是我应该使用的），并且可以为我指明有用的阅读材料的方向，或者可以引导我朝着更有用的方向前进，我将不胜感激它。

提前致谢。

4

2 回答 2

0

我使用数据库中的表来实现安全性。基于表格的方法易于实现、易于理解，并且通过简单地将表格连接到要修剪的项目表来提供安全修剪。报告很简单，基于表格的安全性也可以用于角色。

我只是发现 ASP.NET MVC 中现有的安全模型很麻烦，它并没有做一些我需要它做的事情。特别是，很难将属性应用于需要从数据库访问 ID 的文档记录之类的内容，因为您最终会查找记录两次；一次在属性类中，一次在控制器方法的存储库中。

在所有其他条件相同的情况下，我宁愿维护一个安全系统而不是两个。所以我使用内置的安全性来验证用户，但之后我切换到基于表的安全性。

于 2009-11-19T15:54:52.483 回答
0

我在一些书籍和许多博客中读到，要走的路是基于微软提供的基类实现自己的 MembershipProvider、RoleProvider 和 ProfileProvider，这就是我所做的。但最后，我最终将所有代码更改为我自己的基于自定义的安全模式，这为我提供了所需的所有灵活性。

问题是这些提供商做出了许多可能无法适应您的系统的假设。例如，MembershipProvider 的 create 方法需要问题和答案作为参数（我不需要），或者如果您需要另一个属性，那么编码和维护就变得很麻烦了。我们先不谈测试...

就像你说的，学习体验总是很好，但是为了满足我的需要而必须维护的代码量是不值得的。

至于 AuthorizeAttribute，我所做的是创建了适合我自己的安全模式的过滤器。

我的建议？如果您的要求符合 Microsoft 认为 ProfileProvider 应该是什么样子，那就去做吧。如果没有，请构建自己的。您可以复制他们执行的一些做法，但它使您可以自由地在任何需要的地方进行更改。

于 2009-11-19T18:38:43.230 回答