Don*_*ana 2 c# entity-framework jwt .net-core asp.net-core-2.0
我正在玩.NET Core下的登录程序,我注意到当我按照指南使用时IdentityDbContext,IdentityUser我会在数据库中自动获得一堆表(例如AspNetUsers,AspNetUserClaims等).
虽然很好,但我想知道使用不那么神奇的东西DbContext并为用户和角色管理创建自己的架构是非常错误的.我更喜欢"杀死自己的食物",以便了解安全性如何工作,我不喜欢使用我不理解的螺栓和螺母的工具和框架.("它就像那样工作",当它停止工作时经常导致问题.)
是身份的一部分IdentityDbContext,IdentityUser等等只是一个方便啄或者是那些应该被使用？
我将定位的技术堆栈是.NET Core 2.0和JWT身份验证.当然,该模型应该由EF在DB中管理.
如果问题是愚蠢的,请原谅.我是安全人员的新手,可能正在咆哮错误的树.
不需要使用这些类.它们是经过测试的便捷实现,适合大多数常见用例,但您可以替换或自定义Identity堆栈的各个方面.
标识堆栈具有以下组件:
UserManager,RoleManager和类似的类是从使用的应用程序内的数据进行必要的"业务"的操作.虽然您可以使用自定义实现替换它们,但几乎没有必要.UserStore,RoleStore以及类似的用于对他们所管理的类型进行核心数据操作.您可以提供自定义实现来替换使用的存储机制.提供的商店使用实体框架对托管类型执行数据操作.您可以替换它们以实现其他商店类型.如果您要将用户数据存储为ElasticSearch中的文档,那么这将是要实现的接口.IdentityUser,IdentityRole等是保存有关用户/角色/要求信息的默认实体类型/ ..这些类型可以被继承来扩展它们,或者如果你愿意,你可以使用不同的类.例如,如果您要存储在ElasticSearch中,则可以重用这些类型以避免创建自定义类型来保存用户数据.如果您希望使用它们存储自定义信息,则构建默认存储(实体框架)以处理子类.但是,只要您实现了一个知道如何使用它们的自定义商店并且它们至少有一个Id和一个UserName属性,您就不必使用并且可以使用您喜欢的任何类.有关自定义选项的详细信息,请参阅ASP.NET Core Identity文档的自定义存储提供程序页面.
| 归档时间： |
|
| 查看次数： |
205 次 |
| 最近记录： |