Currently I am having difficulties to get my users to be ported to the EpiServer common tables on the community database.My configuration file looks like this:
<roleManager enabled="true" defaultProvider="SqlServerRoleProvider" cacheRolesInCookie="true">
<add name="SqlServerRoleProvider" connectionStringName="PlatformMembership" applicationName="ApplicationName" type="System.Web.Security.SqlRoleProvider, System.Web, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<membership defaultProvider="EPiServerCommonIntegrationMembershipProvider" userIsOnlineTimeWindow="10">
<add name="EPiServerCommonIntegrationMembershipProvider" applicationName=" ApplicationName " type="EPiServer.Common.Web.Authorization.IntegrationMembershipProvider, EPiServer.Common.Web.Authorization" provider="SqlServerMembershipProvider" roleToSynchronize1="*" />
<add name="SqlServerMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="PlatformMembership" requiresQuestionAndAnswer="false" applicationName=" ApplicationName " requiresUniqueEmail="false" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="8" minRequiredNonalphanumericCharacters="3" passwordAttemptWindow="20" />
I followed the instructions on Tom's post to configure the integration and did not apply the hotfix as I am using the latest CMS and Community from EpiServer.Any suggestion?
Thanks for getting back Kristoffer, I did the post once again so it looks better
I'mdouble checkinng the login control and making sure it is using the right provider as you suggested and will update soon.
Has anyone had a chance to look into this, it is getting critical for us.
It seems like you are using code from the Relate+ package, but maybe not a Relate+ default database?! In the default Relate+ setup there is a custom attribute named "Owner" on the ImageGallery object.
You can check your custom attributes by login into to edit mode -> Community tabb -> Attributes -> choose ImageGallery in the dropdown. If there is no attribute named Owner, you can add it - it should be of type EPiServer.Common.Security.IUser (see documentation if you need information how to do this). Alternatively you can alter the code on the site.
Best regards,Tom Stenius
Many thanks Tom, it is working now.
Have a great day.
Hi! I think Im having the same problem as above. The user exists on the current membership database (Windows) but it does not get "created" in the community tables. This is from web.config
We are using integrated windows authentication (not anonymous acces). Any ideas?
I did not have to use the WindowsMembershipProvider but I assuming it works in a similar way on matters of EpiServer membership integration but double check Tom's post.
What solved my problem was to set the custom attribute named "Owner" on the ImageGallery object as suggested by Tom and that is due to the fact we have used code from the Relate+ package and not a Relate+ default database.
I would maybe suggest to change the roleToSynchronize1="Everyone" to roleToSynchronize1="*" but I am not sure if it will make any difference.
Hope that helps somehow and good luck.
In the Windows Authentication setup you have to approch it a bit differently. See my new blog post here.
Excellent post, that did the trick! :) Thanks
(Remember to remove the preCondition="managedHandler" attribute if you're not using IIS7)
I will add your note to my blog post as well.
I'm sorry to say that I don't beleive you can change this behavior. Either you do as you propose, i.e. create a new user attribute. Or you reverse engineer the HTTP module and make your own with custom behavior.
Each time a user logs in the IntegrationMembershipProvider calls the SynchronizeUser Method of the Integrator class in EPiServer.Common.Web.Authorization namespace. If the Email property is empty for the user in the underlying MembershipProvider it gets copied to the CommonUser-table overwriting any information registered there. One solution is to write the email address of the user back to the underlying MembershipProvider.