重用 DotNetNuke 会员资格/角色/配置文件提供程序
我们当前有一个现有的 ASP.NET 应用程序，希望将其迁移到 DNN。不幸的是，由于时间限制，我们需要逐个移动它（或逐个功能......但是你想看它）。而且，在迁移到 DNN 时，我们希望在现有应用程序中利用当前 (DNN 6.0) 版本的成员资格、角色和个人资料提供程序。我似乎让会员提供者在工作，但是，关于角色和个人资料提供者，我正在经历“最好的方法是什么”时刻之一。
因此，我的问题是：
- 我是否应该利用 DNN 核心的代码为角色和配置文件提供程序创建自定义提供程序？还有其他人这样做过吗？
- 或者我可以/应该利用 DNN 程序集来实现这些功能吗？我很想知道这是否可能（仅使用程序集、更新 web.config 等）？
任何其他建议将不胜感激！
提前致谢！
We currently have an existing ASP.NET application that we want to migrate to DNN. Unfortunately, due to time constraints, we need to move it piece-by-piece (or function-by-function... however you want to look at it). And, we would like to leverage the current (DNN 6.0) version of the membership, roles and profile providers in our existing application while we are moving to DNN. I seem to have the membership provider working, but, I am having one of those 'what is the best way to do this' moments in regards to the roles and profile providers.
So, my questions are:
- Should I create a custom provider for roles and profile providers leveraging code from the DNN core? Has anyone else done this?
- Or can/should I leverage the DNN assemblies for these? I'm very interested to know if this is even possible (just using the assemblies, updating web.config, etc.)??
Any other suggestions would be greatly appreciated!
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我不认为有理由创建一组自定义的提供程序，并且认为您应该可以使用产品附带的“核心”提供程序（因此没有开发的理由）。您面临的挑战将是如何让现有用户（及其所有数据）进入新的 DNN 安装。如何导入此数据的选项各不相同，从自定义开发（用户导入应用程序/模块）到允许用户从各种来源导入的第三方模块（一般来说，单独的 SQL 脚本将很难使用，特别是当您考虑密码哈希时） /security 以及所有数据如何分布在多个表中，其中一些在前面的答案中提到）。
Personally, I don't see a reason to create a custom set of providers and feel you should be fine using the 'core' ones that ship with the product (thus no reason for development). Your challenge is going to be how you will get your existing users (and all their data) into the new DNN install. Your options for how to import this data vary from custom development (of a user import app/module) to third party modules that allow user import from various sources (in general, SQL scripts alone will be difficult to use especially when you consider password hashing/security and how all the data is spread out in multiple tables some of which were mentioned in the previous answer).
如果您要利用 DotNetNuke 中的角色、配置文件、用户帐户，那么您可能需要做更多的事情，而不仅仅是实现自定义提供程序。
DNN 与标准 ASP.NET 成员资格提供程序表交互，但也使用用户表以及附加表来存储自定义用户配置文件信息。还使用特定于 DNN 的用户角色表。
因此，当创建或更新帐户时，它会影响很多地方。
我还没有这样做，但 DNN 使用提供程序来访问 ASP.net 会员资格内容。过去曾宣传过，您可以将其指向另一个系统 ASP 成员资格表，它应该可以工作。
因此，最好让您的应用程序使用标准的 asp net 成员资格表，然后在时机成熟时将 DNN 指向您的表。
If you are going to leverage the roles, profiles, user accounts in DotNetNuke then you would probably need to do more then just implement a custom provider.
DNN interacts with the standard ASP.NET membership provider tables but also uses a Users table as well as an additional table to store information for custom user profile information. Also uses a User Roles table specific to DNN.
So when an account is created or updated it affects a lot of places.
I've not done it, but DNN uses a provider to access the ASP.net membership stuff. It's been advertised in the past that you can point that at another systems ASP membership tables and it should work.
So it might be best to have your app use the standard asp net membership tables, then just point DNN to your tables when the time comes.