在自定义控件中使用 ASP.NET 成员资格提供程序的字符串资源
我请求为 ASP.NET 成员资格构建自定义控件。该控件是一种CreateUserWizard,但有些特殊。用户由我们的客户主管创建。用户首次登录时,输入用户名和初始密码,更改密码并在一次交易中输入附加信息(电子邮件)!
通过自定义 CreateUserWizard 或其他内置控件来构建它似乎是错误的方法。我想通过使用内置控件的字符串资源来构建自定义控件。有没有办法只访问 ASP.NET 会员资源?他们是公共可访问的资源管理器还是类似的东西?
I have the request to build a custom control for ASP.NET membership. The control is a kind of CreateUserWizard, but somewhat special. The users are created by our account executives. At their first log in the users enter their user name and initial password, change the password and enter additional information (email) in one transaction!
Building this by customizing CreateUserWizard or another built-in control seems to be the wrong way. I want to build a custom control by using string resources of the built-in controls. Is there a way to access just the resources of ASP.NET membership? Is their a public accessible resource manager or something similar?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
MembershipProvider 模型公开所有属性 (更新的链接)可通过 web.config 配置,因此一旦您掌握了正确提供程序的实例,您应该能够读取这些属性 - 您无法读取什么?
此外,大多数默认控件允许您使用 模板添加或替换控件元素或通过向创建用户向导添加其他步骤(例如填充个人资料信息)-您能否提供有关您正在尝试执行的操作的任何其他信息?
回复评论/问题更新
我对此有一些进一步的想法,一些是围绕您需要涵盖的想法,还有一些是关于潜在的实施。
一旦客户主管创建了用户,并以某种方式(电话/电子邮件/其他)告知他们用户名和临时密码,他们应该在哪里登录?您的主站点登录控件是您的,还是您乐意将他们引导至自定义登录页面?
仔细思考这一点,并根据您在网站上拥有的登录控件的数量(即您是否只有一个用户可以登录的地方,或者您是否有多个页面),您可能需要实现以下部分或全部:
Authenticate
事件。您可能想要使用自定义成员资格提供程序的原因是,它将使您能够利用诸如基本提供程序的
已批准
用户 - 开箱即用的SqlMebershipProvider
的问题是如果用户未获批准,则在尝试验证用户时将返回 false,这使得在自定义控件中很难区分错误密码和“未批准”用户。如果您创建自定义控件并拥有上面讨论的自定义成员资格提供程序,则您可以将新用户定向到托管该控件的页面,这将确保他们提供所有其他详细信息,当他们提交页面时,您将执行以下操作:
ValidateUser
(在您的自定义会员资格提供商上)。ChangePassword
。GetUser
以获取MembershipUser
,将其电子邮件地址和“IsApproved”状态更新为 true,并将 MembershipUser 对象传递到UpdateUser
> 方法。FormsAuthentication.SetAuthCookie
为用户设置 cookie,以告知后续请求该用户已通过身份验证。如果前两个返回 false,则您可以用一条明智的消息进行响应 - 如果 ValidateUser 失败,则先前提供的详细信息是错误的,如果 ChangePassword 失败,则新密码不符合提供程序配置中定义的要求长度、强度等。
您可能还想挂钩主登录表单的身份验证事件,因为您需要手动检查用户是否已批准,如果没有则取消登录事件。解决这个问题的方法(特别是如果您扩展 SqlMembershipProvider)是配置开箱即用的 SqlMembershipProvider 和您的自定义提供程序,将 SqlMembershipProvider 设置为默认值,然后在您的自定义控件中,而不是调用
: :
您可以使用相同的方法来获取已配置的提供程序的各种属性,例如强度、长度等。
请记住,
CreateUser
方法有一个类型为<的输出参数a href="http://msdn.microsoft.com/en-us/library/system.web.security.membershipcreatestatus.aspx" rel="nofollow noreferrer">MembershipCreateStatus
,其中包含Success
、InvalidUserName
、InvalidPassword
、DuplicateUserName
等值,这应该有助于将合理的消息返回给客户主管。The MembershipProvider model exposes all the properties (updated link) that are configurable through the web.config, so once you've got hold of an instance of the correct provider, you should be able to read those properties - what are you unable to read?
Also, most of the default controls allow you to add or replace controls using either the Template elements or through adding additional steps to the create user wizard (for example to populate profile information) - are you able to provide any additional information about what you are trying to do?
Responding to comment/question update
I've had some further thoughts about this, some around the thinking you'll need to have covered, and some about the potential implementation.
Once a user is created by the account executive, and they are informed of their username and temporary password some how (phone/email/whatever), where do they go to log in? Is your main site login control, or are you happy to direct them to a custom login page?
Thinking this through, and depending on the number of login controls you have on the site (i.e. do you just have one place where users can log in, or do you multiple pages), you may want to implement some or all of the following:
ValidateUser
andChangePassword
, passing all other methods back down to the base default.Authenticate
event of the main login control.The reason you might want to use a custom membership provider is that it will enable you to take advantage of things like the base provider's concept of an
Approved
user - the problem with the out of the boxSqlMebershipProvider
is that it will returnfalse
when attempting to validate the user if it's not approved, which makes it hard to distinguish between incorrect passwords and "not approved" users in your custom control.If you create a custom control and have the custom membership provider discussed above, you can then direct the new users to a page hosting that control which will ensure that they provide all the additional details, when they submit the page you would do the following:
ValidateUser
(on your custom membership provider) with the details created by the account executive.ChangePassword
with the user, old and new passwords.GetUser
on your provider to get aMembershipUser
, update their email address and "IsApproved" status to true, and pass the MembershipUser object into theUpdateUser
method.FormsAuthentication.SetAuthCookie
to set the cookie for the user to tell subsequent requests that the user is authenticated.If either of the first two return false, you can then respond back with a sensible message - if ValidateUser fails, then the previously supplied details are wrong, if ChangePassword failed then the new password didn't meet the requirements defined in the provider configuration for length, strength, etc.
You may also want to hook into the Authenticate event of the main login form because you will need to manually check that the user is Approved and if not cancel the login event. A way around this (especially if you're extending the SqlMembershipProvider) is to configure both the out of the box SqlMembershipProvider and your custom provider, set the SqlMembershipProvider as the default, and then in your custom control, instead of calling:
You would call:
You can use the same method to get a the various properties of the provider that have been configured, such as strength, length, etc.
Bear in mind that the
CreateUser
method has an output parameter of typeMembershipCreateStatus
, which has values such asSuccess
,InvalidUserName
,InvalidPassword
,DuplicateUserName
, which should help in returning sensible messages back to the account executives.