考虑到以下要求，我想推出自己的身份验证/授权系统是错误的吗？
在我的宠物项目中，我希望拥有一个满足以下要求的用户系统：
- 它需要与 Db4o 一起使用持久化模型
- 我想使用 DI（通过 Turbine）将所需的依赖项传递给我的用户模型
- 它需要很容易插入到 asp.net-mvc
- 它需要可以轻松测试
- 它需要支持匿名用户，就像
- 我希望将身份验证和授权分开一样（第一个可以没有第二个）
- 它需要安全起见，
我知道我在这里将一些技术放在功能之前，但由于这是一个宠物项目，并且我想学习一些新东西，我认为将它们作为需求包含在内是合理的。
在自己动手的过程中，我意识到我可能患有某种 NIH 综合症。
由于我不太喜欢 asp.net 中现有的用户框架有多么不必要的复杂，它实际上主要只是有关安全性的所有更复杂的东西，现在让我产生了一些疑问。 继续我自己的行动是否值得捍卫？如果不是，您将如何利用现有的基于 IPrinciple 的框架来满足所有上述要求？
In my pet project I want to have a user system with the following requirements:
- It needs to work with Db4o as a persistance model
- I want to use DI (by means of Turbine) to deliver the needed dependencies to my user model
- It needs to be easy to plug in to asp.net-mvc
- It needs to be testable without much hassle
- It needs to support anonymous users much like SO does
- I want Authentication and Authorization separated (the first can live without the second)
- It needs to be safe
I'm aware I'm putting a few technologies before functionalities here, but as it is a pet project and I want to learn some new stuff I think it is reasonable to include them as requirements.
Halfway in rolling my own I realized I am probably suffering some NIH syndrome.
As I don't really like how needlessly complex the existing user framework in asp.net is, it is actually mostly only all the more complicated stuff regarding security that's now giving me some doubts.
Would it be defendable to go on and roll my own? If not how would you go about fulfilling all the above requirements with the existing IPrinciple based framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在我看来，您想要做的就是推出您自己的自定义 .NET 会员提供程序。
它将允许您在控制器操作上使用内置的 ASP.NET 身份验证
/Authorization属性s，同时让您完全控制提供程序内部的实现（这将允许您对其进行编码以满足上述要求）。直接来自 MSDN...
实现成员资格提供程序
It sounds to me like what you want to do is roll your own Custom .NET Membership Provider.
It will allow you to use the built-in ASP.NET Authentication
/Authorizationattributeson your Controller Actions while giving you complete control over the implementation inside the provider (which will allow you to code it to meet the requirements stated above).Direct from MSDN...
Implementing a Membership Provider
我认为你认识到你考虑的薄弱部分在哪里：即你已经将如何做你正在做的事情作为你这样做的动机和国家卫生研究院（有趣的是：我以前从未见过这一点） ） 问题。
抛开这些不谈，您的提供程序是您可以重用的，并且它可以简化您未来的一些工作。它还应该有助于您进一步熟悉该问题。只要您了解 ASP.NET 框架，以便在需要时也可以使用它（并且不专业，因此如果您不使用工具，您将不知道自己在做什么），那么我相信你已经精心设计了你的防御。
正如 DOK 提到的，请注意，无论您的其他功能是什么，您都不要在这里自行部署，以避免手头的更大任务。不要让这成为一种干扰：它应该是您的应用程序真正需要的东西。如果不是，那么我会倾向于专注于软件的核心任务。
I think you recognize where the thin parts in your consideration are: namely in that you've included how to do what you're doing as motive in why you're doing it and the NIH (funny: I'd never seen that before) issue.
Putting those aside, your provider is something that you could potentially reuse and it may simplify some of your future efforts. It should also serve to familiarize you further with the issue. As long as you understand the ASP.NET framework so you can work with it too if you need to (and aren't specialized such that you don't know what you're doing if you're not using your tool) then I believe you've already crafted your defense.
As DOK mentioned, be cautious that you're not rolling your own here to avoid a larger task at hand in whatever your other functionality is. Don't let this be a distraction: it should be something your application really needs. If it's not, then I'd lean towards focusing on your software's core mission instead.
如果您继续创建自己的自定义解决方案，您将更好地了解它的难度以及您想要什么功能。这将帮助您评估未来项目的现成解决方案。
OTOH，花时间开发已经可用的功能意味着您不会花时间研究项目的主要功能。除非身份验证和授权是您项目的主要组成部分，否则您可能会考虑在另一个领域投入时间并扩展您的知识。
If you go ahead and create your own custom solution, you will have a better idea of how difficult it is and what features you want. This will help you to evaluate off-the-shelf solutions for future projects.
OTOH, spending time developing functionality that is already readily available means you won't be spending that time working on the major functionality of your project. Unless authentication and authorization are a major component of your project, you might consider investing your time, and expanding your knowledge, in another area.
我也在使用 ASP.net MVC 和 db4o 开发一个宠物项目，并做了同样的事情，所以至少你不是唯一一个走这条路的人:)。我开始使用 db4o 作为持久层的最大原因之一是，如果你被迫使用复杂的 SQL 语句和贫乏的域模型。
由于我有复杂的授权需求，需要在 db4o 和 Solr 索引中持久化（和同步），所以我开始致力于推出自己的索引，但只是因为我预先知道这是我的宠物项目的关键功能之一，所以我开始尝试推出自己的索引。想要100%的控制权。
现在，我可能仍然使用 .Net 会员资格提供程序进行身份验证，但不（仅）用于对象授权，但只有在我使用我自己的 POC 验证我的授权需求之后。
I too am working on a pet Project using ASP.net MVC and db4o and did the same thing, so you're at least not alone in going down that route :). One of the biggest reasons for me to start playing around with db4o as persistence layer is that especially authorization on field level (i.e I'm allowed to see Person A's first name but not Person B's first name) is though to achieve if you're forced into complex SQL statements and an anemic domain model.
Since I had complex authorization needs that needed to be persisted (and synchronized) in both db4o and Solr indexes I started working on rolling out my own, but only because I knew up front it was one of the key features of my pet project that I wanted 100% control over.
Now I might still use the .Net Membership provider for authentication but not (solely) for authorization of objects but only after i POC'd my authorization needs using my own.