We have two membership types, one of which is already in Umbraco and working. The other I'm trying to avoid putting into the CMS as there a lot of them and they don't need to be managed in the CMS at all (they're pushed from and updated by an outside source)
Anyone already doing something like this? I.e. running UmbracoMembership alongside asp.net membership? I'd love to know the details.
Yes, this is indeed possible! I have made such in implementation during the last couple of days and it works great as long as you are aware of which MembershipProvider you are using in your code for Login, Registration and such. If you just use Membership.GetUser(); you will most likely default to your Umbraco Provider, so instead you can do something like Membership.Providers["MyAspNetProvider"].GetUser(userName, isOnline); where MyAspNetProvider is the provider name from your web.config.
Let me know if you need some more concrete examples.
I'd actually combine them into a single membership store (preferably the SqlMembership one) rather than having two. And you can change the web.config to use just the asp.net one from within Umbraco itself. It'd make management simpler of the member base as a whole too.
But no, there isn't a reason why you can't have multiple membership providers configured, and you can access the different ones as Morten has shown.
The standard ASP.NET UserControl's might need some configuration through.
Am I right in assuming that everything will have to be done programmatically and we'd lose the easy drag and drop functionality of all the login controls?
The login controls have a "MembershipProvider" property where you can specify the name of the membership provider to use. So, even if you want to use a separate membership provider for your controls, it should not be that different to implement than if you use the "default" provider.
As I understand it, the UmbracoMembership classes have replaced the SqlMembership classes - is this correct or will just pointing the controls at the correct provider work straight away?
UmbracoMembership is indeed the default settings, but it can live side-by-side with the SqlMembership. If you define a separate provider "MyMembershipProvider" in your web.config and you configure it to use the SqlMembership classes, then the only thing you need to do in your controls is fill in the MembershipProvider property with "MyMembershipProvider". And they will then link straight to the" asp_net SQL" version of the provider.
How do you then identify which Provider the member has logged in as? I.e. HttpContext.Current.User.Identity.Name only returns the username, which for us is not unique between the two providers (and can't be due to the data provided).
I have never come to that situation, but logically, this would have to be the Provider you specified when programming the user login, either via the ASP.Net login control (MembershipProvider property), either via custom code. Normally, at some point in the logon procedure, you will have to specify which provider to log in to, and this is the one that is then used throughout the site.
If you need to identify the Provider from user name anyway, I guess what you can do is loop through the available Membership Providers and check which one returns you a user mapping the HttpContext.Current.User.Identity.Name.
So, something like this (.Net 3.5):
var myProvider = Membership.Providers.OfType<MembershipProvider>().FirstOrDefault(x => x.GetUser(HttpContext.Current.User.Identity.Name, true) != null);
This would return the first (and unique in your case) Provider which actually returns a MembershipUser when you look for it by username, or null if no matching provider is found. I haven't tested the Linq query so it might not work right away (you might actually need to use a for-loop on this), but at least it gives you an idea of the way to go.
Cheers for the replies. The problem is that the usernames are not unique between the two providers, hence needing a way outside of Identity.Name to identify which part of the site the user logged into. (It's a fairly odd requirement which I hope will eventually be refined)
We have gotten around it by placing a prefix on the username in code.
Umbraco membership alongside standard asp.net membership?
Can the two run alongside each other?
We have two membership types, one of which is already in Umbraco and working. The other I'm trying to avoid putting into the CMS as there a lot of them and they don't need to be managed in the CMS at all (they're pushed from and updated by an outside source)
Anyone already doing something like this? I.e. running UmbracoMembership alongside asp.net membership? I'd love to know the details.
Cheers!
Hi Pete,
Yes, this is indeed possible! I have made such in implementation during the last couple of days and it works great as long as you are aware of which MembershipProvider you are using in your code for Login, Registration and such. If you just use Membership.GetUser(); you will most likely default to your Umbraco Provider, so instead you can do something like Membership.Providers["MyAspNetProvider"].GetUser(userName, isOnline); where MyAspNetProvider is the provider name from your web.config.
Let me know if you need some more concrete examples.
- Morten
I'd actually combine them into a single membership store (preferably the SqlMembership one) rather than having two. And you can change the web.config to use just the asp.net one from within Umbraco itself. It'd make management simpler of the member base as a whole too.
But no, there isn't a reason why you can't have multiple membership providers configured, and you can access the different ones as Morten has shown.
The standard ASP.NET UserControl's might need some configuration through.
Thanks for the replies, guys.
Am I right in assuming that everything will have to be done programmatically and we'd lose the easy drag and drop functionality of all the login controls?
Hi Pete,
The login controls have a "MembershipProvider" property where you can specify the name of the membership provider to use. So, even if you want to use a separate membership provider for your controls, it should not be that different to implement than if you use the "default" provider.
Cheers!
Michael.
Great stuff, thanks.
As I understand it, the UmbracoMembership classes have replaced the SqlMembership classes - is this correct or will just pointing the controls at the correct provider work straight away?
Cheers!
Hi Pete,
UmbracoMembership is indeed the default settings, but it can live side-by-side with the SqlMembership.
If you define a separate provider "MyMembershipProvider" in your web.config and you configure it to use the SqlMembership classes, then the only thing you need to do in your controls is fill in the MembershipProvider property with "MyMembershipProvider". And they will then link straight to the" asp_net SQL" version of the provider.
Hope this makes sense :-)
Cheers!
A quick follow-up question...
How do you then identify which Provider the member has logged in as? I.e. HttpContext.Current.User.Identity.Name only returns the username, which for us is not unique between the two providers (and can't be due to the data provided).
Hi Pete,
I have never come to that situation, but logically, this would have to be the Provider you specified when programming the user login, either via the ASP.Net login control (MembershipProvider property), either via custom code.
Normally, at some point in the logon procedure, you will have to specify which provider to log in to, and this is the one that is then used throughout the site.
Hi again Pete,
If you need to identify the Provider from user name anyway, I guess what you can do is loop through the available Membership Providers and check which one returns you a user mapping the HttpContext.Current.User.Identity.Name.
So, something like this (.Net 3.5):
This would return the first (and unique in your case) Provider which actually returns a MembershipUser when you look for it by username, or null if no matching provider is found.
I haven't tested the Linq query so it might not work right away (you might actually need to use a for-loop on this), but at least it gives you an idea of the way to go.
Cheers!
Hi guys,
Cheers for the replies. The problem is that the usernames are not unique between the two providers, hence needing a way outside of Identity.Name to identify which part of the site the user logged into. (It's a fairly odd requirement which I hope will eventually be refined)
We have gotten around it by placing a prefix on the username in code.
Cheers!
is working on a reply...