I've been searching around the forum and google and have seen plenty of others have also wanted the ability to have logins inside Umbraco using their own table. I am also in this situation with both the authentication (user and password) and authorization (roles/acls). Is there a best practice for handling a situation like this? I do not fully understand the difference between and user and a member within Umbraco. We have our own user management application so I don't think I need to leverage the built in tools, but for the purpose of checking that a user is logged in, and checking whether the user is in a role.. what is the best practice for Umbraco?
I appreciate any guidance. I am running the 4.7.2 build.
I can see why it can be confusing when it comes to Users/Members if/when you're used to work the the standard ASP.NET MemberShip provider. Users in Umbraco are backend users. I.e., your 'admin' standard user is a User in Umbraco which you use for logging in to the CMS.
Members, on the other hand are basically equal to the ASP.NET MemberShip user :-) A Member group (found in the members section) is an ASP.NET MemberShip Role. So basically, the members section in Umbraco, and members in general, are using the standard ASP.NET MemberShip provider which means you can (and should, since many of the methods and properties on the Member class are deprecated) make use of all the .NET MemberShip tools such as the standard asp:Login control etc and also check if current user is in a Role (Member Group)
What I tend to do when building websites with member is to create a group with a pluralized name such as "Competitors" and then create a Member type (much like a Document type, really) which I would then call "Competitor" which is the member "object" that I will be using. On this member type you are able to define properties such as contact details, last login etc etc.
Thanks Bo! Since I am really only interested in having a custom set of users for the members, I will be implementing a custom membership provider for that. I am looking forward to it and hoping it will be smooth sailing. I don't believe from my reading that I'll have to do anything specific with the members part of the back-office once I have the new membership provider implemented and then configured in the web.config, should just be "plug n play" from what I saw!
Best practices for custom user login and roles?
I've been searching around the forum and google and have seen plenty of others have also wanted the ability to have logins inside Umbraco using their own table. I am also in this situation with both the authentication (user and password) and authorization (roles/acls). Is there a best practice for handling a situation like this? I do not fully understand the difference between and user and a member within Umbraco. We have our own user management application so I don't think I need to leverage the built in tools, but for the purpose of checking that a user is logged in, and checking whether the user is in a role.. what is the best practice for Umbraco?
I appreciate any guidance. I am running the 4.7.2 build.
Hi John,
I can see why it can be confusing when it comes to Users/Members if/when you're used to work the the standard ASP.NET MemberShip provider. Users in Umbraco are backend users. I.e., your 'admin' standard user is a User in Umbraco which you use for logging in to the CMS.
Members, on the other hand are basically equal to the ASP.NET MemberShip user :-) A Member group (found in the members section) is an ASP.NET MemberShip Role. So basically, the members section in Umbraco, and members in general, are using the standard ASP.NET MemberShip provider which means you can (and should, since many of the methods and properties on the Member class are deprecated) make use of all the .NET MemberShip tools such as the standard asp:Login control etc and also check if current user is in a Role (Member Group)
What I tend to do when building websites with member is to create a group with a pluralized name such as "Competitors" and then create a Member type (much like a Document type, really) which I would then call "Competitor" which is the member "object" that I will be using. On this member type you are able to define properties such as contact details, last login etc etc.
Hope this makes sense, else let me know :-)
All the best,
Bo
Thanks Bo! Since I am really only interested in having a custom set of users for the members, I will be implementing a custom membership provider for that. I am looking forward to it and hoping it will be smooth sailing. I don't believe from my reading that I'll have to do anything specific with the members part of the back-office once I have the new membership provider implemented and then configured in the web.config, should just be "plug n play" from what I saw!
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.