I have seen arround the umbraco.org that the new Umbraco is using a .NET Membership provider, and it seems that I should create a member the .NET way, and not with the umbraco classes. Is that right?
wich to me tells me that i should do it another way, but if i try to:
var member =System.Web.Security.Membership.CreateUser("username","password");
It doenst seem to work. And i cant understand why defining a variable should create a member.
Sorry for my stupidity here, but I could use some guidance. Should I just continue down the MakeNew() path, or go the .NET CreateUser() way? And why? :-)
Interesting question! I tried to use the .Net providers in my latest project but to get generic properties from a member object I had to use the Umbraco Member-class anyway. Seems like using the .NET-providers only would work in very "simple" senarios?
I have to add one thing about the .NET membership providers I think that the main reason for the Umbraco-team to implement them is that we can use the standard ASP.NET membership controls like login, loginview, password recovery and so on.
Yes using the legacy system you can use more than 1 member type. If it's to determine the type of user groups might be better. Just add all properties you need on a single member type even the ones you don't need in all situations and you should be good.
Create a Member programmaticly the right way
Hi people,
I have seen arround the umbraco.org that the new Umbraco is using a .NET Membership provider, and it seems that I should create a member the .NET way, and not with the umbraco classes. Is that right?
RIght now I have this function:
Taken from the Nibble tutorial: http://www.nibble.be/?p=20
This seems to work. I can create a Member pretty easy. And maybe I should just be glad and use this. But then I find a page like this:
http://our.umbraco.org/wiki/how-tos/membership-providers
wich to me tells me that i should do it another way, but if i try to:
It doenst seem to work. And i cant understand why defining a variable should create a member.
Sorry for my stupidity here, but I could use some guidance. Should I just continue down the MakeNew() path, or go the .NET CreateUser() way? And why? :-)
/Peter
Interesting question! I tried to use the .Net providers in my latest project but to get generic properties from a member object I had to use the Umbraco Member-class anyway. Seems like using the .NET-providers only would work in very "simple" senarios?
HI Peter,
I assume you get an error? Check your web.config and make sure defaultMemberTypeAlias is set to the correct alias.
The variable you create because CreateUser returns the created Member then you can use that object to set email address etc
Cheers,
Richard
I have to add one thing about the .NET membership providers I think that the main reason for the Umbraco-team to implement them is that we can use the standard ASP.NET membership controls like login, loginview, password recovery and so on.
@Enkelmedia Well I think I found s a solution to that problem.
In the web.config you have to add the custom properties too interact with them:
You can see I added the "name" property as a string :-)
@Richard > I will try the defaultMemberTypeAlias and see what it do to me :-)
But is it right... should that one line then create a new user for me? :-)
/Peter
@Richard > That did the trick. Well certainly can see the smart in this now. It also has a better feel of security when its the .NET classes :-)
Now my function looks like this:
So i can add the group aswell to the user when I create :-)
But what if I want to add a different MemberTypeAlias for a user? How can i do this then? :-)
/Peter
Hi Peter,
You can only use 1 Member type which is valid since in gthe default asp.net Membership API you also have only one type.
Cheers,
Richard
Okay,
But i can add more in the Umbraco system. Guess that for the ones who uses the old system?! :-)
Well.. Then I have to stick with the Member Groups instead, even though I cant give them custom properties.
/Peter
Hi Peter,
Yes using the legacy system you can use more than 1 member type. If it's to determine the type of user groups might be better. Just add all properties you need on a single member type even the ones you don't need in all situations and you should be good.
Cheers,
Richard
Yeah, I think that would be the way im doing it :-)
Thank you both :-)
/Peter
is working on a reply...