For a sso solution we want to implement in umbraco we need to make a small change to the umbraco membership provider. The best way to do this seems to me, to be to check-out the source from svn on codeplex (read only, so I can always do get latest version). This way I can always generate a patch if I wish to submit the code back to the project. Unfortunately it's taking an incredible amount of time to check things out, navigating the sourcetree takes minutes per click (anksvn direct or svnbridge). I notice the same slow access in the codeplex web interface. All other source control connections I use seem to work fine. For me it's just codeplex.
Anyone else experiencing this? Can it be solved? Is it the umbraco project size?
Codeplex is just slow, not something that can be prevented. The Umbraco project is quite large, sure, that doesn't help but it's not huge.
Anyway, instead of changing the membership provider source code, it's recommended you implement your own membership provider for your custom needs. That way, you can always upgrade to a newer Umbraco version without having to re-apply your patch all over again. You can still base it on the Umbraco version and submit your own patch.
Thank you for replying, seems I have to live with the speed then. As to your seccond remark, I came to the conclusion that when I recreate a provider I also have to create a new member section in the admin panel and that seems like a lot af work for a simple sepperate config string
You wouldn't have to create a new member section, you can have your membership provider write to the umbraco member section just fine.
What do you need to change in membership provider anyway? A config string? What for? Maybe if you explain what your intention is, we can help you find an easier way to do it.
We want to make several umbraco sites (different faces of a single organization) share their memberdatabase to provide a single sign on experience to the members. This is not possible as every provider in umbraco (last 4.1 I tested) used the same single connectionstring. I would change the provider to look for an provider specific connectionstring and when that is not available then switch to the standard one. As the connectionstring is put into a single variable and then used in the entire provider, the change would be minor.
As to why not create a new provider. Simple answer is it did not work. When trying to use the default member section it returned casting errors and worse trying to find and locate users using the umbraco member class in the businesslogic project which will revert to the umbracomemberprovider and can't find the user because they use default connection string. To me the member section is thus completely locked to the default membershipprovider. Conclusion I need to change it.
Slow svn access
For a sso solution we want to implement in umbraco we need to make a small change to the umbraco membership provider. The best way to do this seems to me, to be to check-out the source from svn on codeplex (read only, so I can always do get latest version). This way I can always generate a patch if I wish to submit the code back to the project. Unfortunately it's taking an incredible amount of time to check things out, navigating the sourcetree takes minutes per click (anksvn direct or svnbridge). I notice the same slow access in the codeplex web interface. All other source control connections I use seem to work fine. For me it's just codeplex.
Anyone else experiencing this? Can it be solved? Is it the umbraco project size?
Codeplex is just slow, not something that can be prevented. The Umbraco project is quite large, sure, that doesn't help but it's not huge.
Anyway, instead of changing the membership provider source code, it's recommended you implement your own membership provider for your custom needs. That way, you can always upgrade to a newer Umbraco version without having to re-apply your patch all over again. You can still base it on the Umbraco version and submit your own patch.
Thank you for replying, seems I have to live with the speed then. As to your seccond remark, I came to the conclusion that when I recreate a provider I also have to create a new member section in the admin panel and that seems like a lot af work for a simple sepperate config string
You wouldn't have to create a new member section, you can have your membership provider write to the umbraco member section just fine.
What do you need to change in membership provider anyway? A config string? What for? Maybe if you explain what your intention is, we can help you find an easier way to do it.
We want to make several umbraco sites (different faces of a single organization) share their memberdatabase to provide a single sign on experience to the members. This is not possible as every provider in umbraco (last 4.1 I tested) used the same single connectionstring. I would change the provider to look for an provider specific connectionstring and when that is not available then switch to the standard one. As the connectionstring is put into a single variable and then used in the entire provider, the change would be minor.
As to why not create a new provider. Simple answer is it did not work. When trying to use the default member section it returned casting errors and worse trying to find and locate users using the umbraco member class in the businesslogic project which will revert to the umbracomemberprovider and can't find the user because they use default connection string. To me the member section is thus completely locked to the default membershipprovider. Conclusion I need to change it.
Any better insight is welcome
is working on a reply...