会员等级称“错误”我的自定义提供程序上的方法?
我开发了自己的自定义会员资格和角色提供程序。 System.Web.Security.Membership 类调用我尚未实现的 CreateUser 方法(我故意希望在 MembershipUser 中获得更多信息)。
在这种情况下我应该使用 Membership 类吗?
现在我向自己的会员提供者进行类型转换以使用我实现的 CreateUser 方法,这是要走的路吗?我感觉有点失落,我该怎么办?
((MyMembershipProviderBase)Membership.Provider).CreateUser(username, password, email, lastName, firstName, phoneNumber, out status);
会员提供者 CreateUser-methods:
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
throw new NotImplementedException();
}
public MyMembershipUser CreateUser(
string username, string password, string email, string lastName, string firstName,
string phoneNumber, out MembershipCreateStatus status)
{
// implemented...
}
*编辑
对 @elkdanger 评论的回复。
这是您在评论中提到的那种包装吗?
现在,Membership 类调用标准的 CreateUser 方法,该方法重定向到我自己的实现,问题是我无法设置用户的附加信息(名字、姓氏和电话号码)。这是要走的路,然后从其他地方(我创建用户的地方)处理设置附加信息吗?
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion,
string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
return this.CreateUser(username, password, email, "", "", "", out status);
}
public MyMembershipUser CreateUser(
string username, string password, string email, string lastName, string firstName,
string phoneNumber, out MembershipCreateStatus status
)
{
var args =
new ValidatePasswordEventArgs(username, password, true);
OnValidatingPassword(args);
if (args.Cancel)
{
status = MembershipCreateStatus.InvalidPassword;
return null;
}
if (RequiresUniqueEmail && GetUserNameByEmail(email) != "")
{
status = MembershipCreateStatus.DuplicateEmail;
return null;
}
MembershipUser u = GetUser(username, false);
if (u == null)
{
try
{
status = Repository.CreateUser(username, EncodePassword(password), email, lastName, firstName,
phoneNumber);
}
catch
{
status = MembershipCreateStatus.ProviderError;
}
return (MyMembershipUser)GetUser(username, false);
}
else
{
status = MembershipCreateStatus.DuplicateUserName;
return null;
}
}
I have developed my own custom membership and role provider. The System.Web.Security.Membership class calls the CreateUser-method that I haven't implemented (on purpose, I want more information in my MembershipUser).
Should I use the Membership class at all in this scenario?
Now I typecast to my own membership provider to use my implemented CreateUser-method, is this the way to go? I feel a bit lost, how should I handle this?
((MyMembershipProviderBase)Membership.Provider).CreateUser(username, password, email, lastName, firstName, phoneNumber, out status);
Membership provider CreateUser-methods:
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
throw new NotImplementedException();
}
public MyMembershipUser CreateUser(
string username, string password, string email, string lastName, string firstName,
string phoneNumber, out MembershipCreateStatus status)
{
// implemented...
}
*Edit
Respons to @elkdanger comment.
Is this the kind of wrapper you are referring to in your comment?
Now the Membership class calls the standard CreateUser-method that redirects to my own implementation, the problem is that i cant set the additional information for the user (firstname, lastename and phonenumber). Is this the way to go and then handle setting the additional information from somewhere else(where i create my user)?
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion,
string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
return this.CreateUser(username, password, email, "", "", "", out status);
}
public MyMembershipUser CreateUser(
string username, string password, string email, string lastName, string firstName,
string phoneNumber, out MembershipCreateStatus status
)
{
var args =
new ValidatePasswordEventArgs(username, password, true);
OnValidatingPassword(args);
if (args.Cancel)
{
status = MembershipCreateStatus.InvalidPassword;
return null;
}
if (RequiresUniqueEmail && GetUserNameByEmail(email) != "")
{
status = MembershipCreateStatus.DuplicateEmail;
return null;
}
MembershipUser u = GetUser(username, false);
if (u == null)
{
try
{
status = Repository.CreateUser(username, EncodePassword(password), email, lastName, firstName,
phoneNumber);
}
catch
{
status = MembershipCreateStatus.ProviderError;
}
return (MyMembershipUser)GetUser(username, false);
}
else
{
status = MembershipCreateStatus.DuplicateUserName;
return null;
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
通过以这种方式进行转换来访问您的特定实例,您几乎完全绕过了 Asp.Net 会员系统的要点。这个想法是,系统使用已知的合同来管理其用户数据,当您必须以这种方式开始投射时,您就违反了该合同。我很欣赏这可能是一个小小的改变,但无论如何它还是有点“味道”。
此时,您不妨运行自己的实现,因为实际上不会有什么区别,但只要坚持使用现有的,您就会节省一些时间。
如果您想稍微清理一下,我将恢复到 Asp.Net Membership 为您提供重载的原始 CreateUser 方法,但创建一个围绕成员资格功能的包装器,该包装器强制执行您需要传入的所有额外详细信息。如果你不能这样做(也许因为你使用的是 Asp.Net 附带的默认创建用户向导控件),那么我建议你的需求超出了 Asp.Net 会员系统的需求,你会更好从长远来看,设计自己的系统更适合您想要实现的目标。
祝你好运!
By casting in this way to get access to your particular instance, you're almost completely bypassing the point of the Asp.Net Membership system. The idea is that the system works with a known contract for managing its user data, and when you have to start casting in this way you're breaking that contract. I appreciate that it might be a small change, but never-the-less it's a bit of a "smell".
At this point you might as well run your own implementation because there will be no difference really, but you will save some time by just sticking with what you have.
If you want to clean this up a bit, I would revert back to the original CreateUser method that Asp.Net Membership gives you to overload, but create a wrapper around the membership functionality which enforces all the extra detail you need to pass in. If you can't do this (perhaps because you are using the default Create User wizard controls which come with Asp.Net) then I'd suggest your requirements out-grow what the Asp.Net Membership system caters for and you're better off in the long run devising your own system which is more suitable for what you're trying to achieve.
Good luck!