I have an existing website with a requirement to change the membership provider. The existing site is in v6.1.6, because of hosting restrictions the latest it could be upgraded to would be v6.2.4.
The requirement is to have all the membership data including properties and logins in a separate database. This is so that the live database can be overwritten without overwriting the data held on members.
This is due to specific hosting operating procedures of the customer and the way their "go live" security procedures are operated.
I understand that the membership provider changed between v6.1 & v6.2 so I'm wondering is it a good idea to update to v.6.2.4 from v6.1.6 ? The earlier one may be more stable or maybe that later is fine?
The objectctive is to use the membership provider in a separate DB
ideally
that uses the same hash so that passwords can be maintained
that keeps the properties in the alternate db
the properties are still available via the membership functions
I had thought about possibly compiling a "new" Umbraco membership provider from the same source but adjusting this to use a different database.
The providers are custom .Net membership providers so it doesn't really matter that the Umbraco on changed between version as far as what you are trying to do is concerned as you will be creating your own custom .Net membership provider.
We have successfully create a few custom providers and it works very well, do watch out for any code or third party package (such as Ditto) that makes calls to Umbraco.TypedMember though as they will throw YSOD when you switch out the Umbraco provider for you own.
With a custom membership provider is it possible for the membership properties to be stored in the new provider but still available via the membership functions in Umbraco. For example using {member.customProperty} in the contour default text field.
Alternative Membership Provider
I have an existing website with a requirement to change the membership provider. The existing site is in v6.1.6, because of hosting restrictions the latest it could be upgraded to would be v6.2.4.
The requirement is to have all the membership data including properties and logins in a separate database. This is so that the live database can be overwritten without overwriting the data held on members.
This is due to specific hosting operating procedures of the customer and the way their "go live" security procedures are operated.
I understand that the membership provider changed between v6.1 & v6.2 so I'm wondering is it a good idea to update to v.6.2.4 from v6.1.6 ? The earlier one may be more stable or maybe that later is fine?
The objectctive is to use the membership provider in a separate DB ideally that uses the same hash so that passwords can be maintained that keeps the properties in the alternate db the properties are still available via the membership functions
I had thought about possibly compiling a "new" Umbraco membership provider from the same source but adjusting this to use a different database.
Any ideas of if this will work?
Hi John,
The providers are custom .Net membership providers so it doesn't really matter that the Umbraco on changed between version as far as what you are trying to do is concerned as you will be creating your own custom .Net membership provider.
We have successfully create a few custom providers and it works very well, do watch out for any code or third party package (such as Ditto) that makes calls to Umbraco.TypedMember though as they will throw YSOD when you switch out the Umbraco provider for you own.
I hope that's helpful,
Jeavon
Thanks Jeavon - very much appreciated.
With a custom membership provider is it possible for the membership properties to be stored in the new provider but still available via the membership functions in Umbraco. For example using {member.customProperty} in the contour default text field.
Hi John,
I'm don't think so, you will likely need your own API for getting data from your provider.
Jeavon
Do you know what the purpose of the Membership Profile Provider is?
is working on a reply...