Probably someone already asked something similar, but I'm just going to shoot away anyways.
Taking into account the fact that some of the methods in the Member class are marked as obselete I have a few questions:
Whats the new recommended approach to associate a new "Member" with a member type?
Is there another way of accesing member type defined properties without having to define them on the web.config?
If I use the role provider programatically or through the ASP .NET Configuration interface to create new roles will they appear automatically as available user groups?
Besides from filtering (which I already get from groups), what's the point of having member types as a feature on the back-end if the API to manipulate their properties requires for me to segmentate the properties creating new classes for each group?
How long will the deprecated methods from the Member class will be around?
Besides the two video examples on the video library and some Aaron Powell posts related to this topic, is there any formal documentation with examples about how to work with the "new approach"? Something like this?
Whats the new recommended approach to associate a new "Member" with a member type? Is there another way of accesing member type defined properties without having to define them on the web.config?
Personally, I still use the Member methods and properties (even though they are marked as deprecated) to access properties and associate members with a membertype. It's just that much easier than to register every property in the config file. Every purist will tell you otherwise, though ;-)
If I use the role provider programatically or through the ASP .NET Configuration interface to create new roles will they appear automatically as available user groups?
Yes, the role provider Roles are equal to the member groups, so you are able to manipulate it through that.
Besides from filtering (which I already get from groups), what's the point of having member types as a feature on the back-end if the API to manipulate their properties requires for me to segmentate the properties creating new classes for each group?
If we didn't have Member Types in the backend, we wouldn't be able to create different types of members (pretty self-explanatory :-D) The Roles/User Groups are basically "just" to be able to put members of any type in a group which can be used for setting up security in the content section.
How long will the deprecated methods from the Member class will be around?
Honestly don't know. However, I do think the core team were a little too fast when deprecating them since a lot of developers still use the methods and properties today.
Besides the two video examples on the video library and some Aaron Powell posts related to this topic, is there any formal documentation with examples about how to work with the "new approach"? Something like this?
I haven't been able to find any. The WIKI page about Member should be updated some time around, though :-) However, the Members section in Umbraco is "just" the standard ASP.NET Membership provider, so technically, if you're used to working with that from other ASP.NET projects, you should be able to re-use a lot of that logic.
Thanks for taking the time to answer each of my questions.
Parting from your approach of combinating the ASP .NET Membership provider and the Umbraco Member class I'd like to know if this is the way to go for member validation then:
bool isValid= _provider.ValidateUser(userName, password);
if(isValid)
{
Member member = Member.GetMemberFromEmail(userName);
Member.AddMemberToCache(member);
}
Or is it enough with the Validation method of the Membership provider?
Going deeper on my investigation about what's the correct way of handling Members in Umbraco I found myself swimming through the source code of the UmbracoMembershipProvider class. I made an interesting finding while checking out the Create method implementation. Here's the source code from that particular method:
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion,
string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
if (Member.GetMemberFromLoginName(username) != null)
status = MembershipCreateStatus.DuplicateUserName;
else if (Member.GetMemberFromEmail(email) != null)
status = MembershipCreateStatus.DuplicateEmail;
else
{
Member m = Member.MakeNew(username, email, MemberType.GetByAlias(m_DefaultMemberTypeAlias), User.GetUser(0));
m.Password = password;
MembershipUser mUser =
ConvertToMembershipUser(m);
// custom fields
if (!String.IsNullOrEmpty(m_PasswordRetrievalQuestionPropertyTypeAlias))
updateMemberProperty(m, m_PasswordRetrievalQuestionPropertyTypeAlias, passwordQuestion);
if (!String.IsNullOrEmpty(m_PasswordRetrievalAnswerPropertyTypeAlias))
updateMemberProperty(m, m_PasswordRetrievalAnswerPropertyTypeAlias, passwordAnswer);
if (!String.IsNullOrEmpty(m_ApprovedPropertyTypeAlias))
updateMemberProperty(m, m_ApprovedPropertyTypeAlias, isApproved);
if (!String.IsNullOrEmpty(m_LastLoginPropertyTypeAlias)) {
mUser.LastActivityDate = DateTime.Now;
updateMemberProperty(m, m_LastLoginPropertyTypeAlias, mUser.LastActivityDate);
}
// save
m.Save();
status = MembershipCreateStatus.Success;
return mUser;
}
return null;
}
As you can see, ironically, the recommended way of handling the Members, uses the obsolete way internally. The Create method of the UmbracoMembershipProvider and other method overrides are just a lame façade for the old Member class. Maybe in the future they want to change the implementation and eliminate completely the use of the Member class but right now the approach taken is misleading and confusing.
I guess I'll have to concur with you on the fact that decorating the Member class methods as obsolete is a little bit of a rushed decision.
Another funny thing is that some arguments get ignored like the value for the providerUserKey, since the Id is generated internally by the Member class anyways.
Umbraco Members & ASP .NET Membership
Hi,
Probably someone already asked something similar, but I'm just going to shoot away anyways.
Taking into account the fact that some of the methods in the Member class are marked as obselete I have a few questions:
Hi Raoul,
I'll try to answer this as best as I can :-)
Whats the new recommended approach to associate a new "Member" with a member type?
Is there another way of accesing member type defined properties without having to define them on the web.config?
Personally, I still use the Member methods and properties (even though they are marked as deprecated) to access properties and associate members with a membertype. It's just that much easier than to register every property in the config file. Every purist will tell you otherwise, though ;-)
If I use the role provider programatically or through the ASP .NET Configuration interface to create new roles will they appear automatically as available user groups?
Yes, the role provider Roles are equal to the member groups, so you are able to manipulate it through that.
Besides from filtering (which I already get from groups), what's the point of having member types as a feature on the back-end if the API to manipulate their properties requires for me to segmentate the properties creating new classes for each group?
If we didn't have Member Types in the backend, we wouldn't be able to create different types of members (pretty self-explanatory :-D) The Roles/User Groups are basically "just" to be able to put members of any type in a group which can be used for setting up security in the content section.
How long will the deprecated methods from the Member class will be around?
Honestly don't know. However, I do think the core team were a little too fast when deprecating them since a lot of developers still use the methods and properties today.
Besides the two video examples on the video library and some Aaron Powell posts related to this topic, is there any formal documentation with examples about how to work with the "new approach"? Something like this?
I haven't been able to find any. The WIKI page about Member should be updated some time around, though :-) However, the Members section in Umbraco is "just" the standard ASP.NET Membership provider, so technically, if you're used to working with that from other ASP.NET projects, you should be able to re-use a lot of that logic.
Let me know if the above makes sense ;-)
All the best,
Bo
Hi Bo,
Thanks for taking the time to answer each of my questions.
Parting from your approach of combinating the ASP .NET Membership provider and the Umbraco Member class I'd like to know if this is the way to go for member validation then:
Or is it enough with the Validation method of the Membership provider?
Going deeper on my investigation about what's the correct way of handling Members in Umbraco I found myself swimming through the source code of the UmbracoMembershipProvider class. I made an interesting finding while checking out the Create method implementation. Here's the source code from that particular method:
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status) { if (Member.GetMemberFromLoginName(username) != null) status = MembershipCreateStatus.DuplicateUserName; else if (Member.GetMemberFromEmail(email) != null) status = MembershipCreateStatus.DuplicateEmail; else { Member m = Member.MakeNew(username, email, MemberType.GetByAlias(m_DefaultMemberTypeAlias), User.GetUser(0)); m.Password = password; MembershipUser mUser = ConvertToMembershipUser(m); // custom fields if (!String.IsNullOrEmpty(m_PasswordRetrievalQuestionPropertyTypeAlias)) updateMemberProperty(m, m_PasswordRetrievalQuestionPropertyTypeAlias, passwordQuestion); if (!String.IsNullOrEmpty(m_PasswordRetrievalAnswerPropertyTypeAlias)) updateMemberProperty(m, m_PasswordRetrievalAnswerPropertyTypeAlias, passwordAnswer); if (!String.IsNullOrEmpty(m_ApprovedPropertyTypeAlias)) updateMemberProperty(m, m_ApprovedPropertyTypeAlias, isApproved); if (!String.IsNullOrEmpty(m_LastLoginPropertyTypeAlias)) { mUser.LastActivityDate = DateTime.Now; updateMemberProperty(m, m_LastLoginPropertyTypeAlias, mUser.LastActivityDate); } // save m.Save(); status = MembershipCreateStatus.Success; return mUser; } return null; }As you can see, ironically, the recommended way of handling the Members, uses the obsolete way internally. The Create method of the UmbracoMembershipProvider and other method overrides are just a lame façade for the old Member class. Maybe in the future they want to change the implementation and eliminate completely the use of the Member class but right now the approach taken is misleading and confusing.
I guess I'll have to concur with you on the fact that decorating the Member class methods as obsolete is a little bit of a rushed decision.
Another funny thing is that some arguments get ignored like the value for the providerUserKey, since the Id is generated internally by the Member class anyways.
is working on a reply...