I think you would like to prevent the new user from being created, so yes, you should probably create your own user integration code based on / insipred by the shipping IntegrationHttpModule. I would probably save the AD guid in an attribute for each user and search for that instead of the user name when determining if a user should be created or updated.
We use our own integrating module for other reasons but it is basically built from scratch, since the shipping module isn't really structured in a way thet lends itself to modifications (private and static methods etc).
Yes thats pretty much along my thoughts. We actually store the AD guid as IUser.Alias for identification. So my idea would be to ask AD for the Guid based on the new username and check if there exist a community user already. But when looking at the IntegrationHttpModule in Object Browser in VS, it lies in parallel with Integrator. I don't have any reflector software yet so I don't know the relationship between the module and the Integrator class. Is there a way to configure so that MyIntegrator is used instead of Integrator? Thanks.
No, it's not easily extendible in any way. The module checks if the user should be integrated (someone is logged on and a cookie that signals that the integration has already been run for the session is not set). Then it calls the static SynchronizeUser method in Integrator. So there's no way to intercept that call.
However, there isn't really that much code and it's quite easy to follow so if you can reflect it you should have a pretty good idea how to build your own module. The basic idea is really just to use a module and in its Init method hook the AuthenticateRequest event and in that event handler update or create a user if there is a logged in user not present in the community system, then synchronize the group memberships etc. The cookie it sets is just to prevent this code from running on every request which is quite unnecessary since the user's properties and roles are not expected to change that often.
I implemented two classes, one MyIntegrationHttpModule and one MyIntegrator. I changed web.config to use MyIntegrationHttpModule like this:
<add name="EPiServerCommonWindowsAuthenticationIntegration" type="MyAssembly.MyIntegrationHttpModule, MyAssembly" />
But when debugging I never get to my new Init() method. I can't find where the Init() is called. Do I need to configure anything else to make my module available? Or do I have to find the code that calls the Init() and override it as well?
UPDATE: I got it to work by creating a whole new IntegrationHttpModule instead of inheriting the shipping one. I thought that just by adding 'new' to the Init() method and the event method it should work.
Thank you Magnus for your replies, it has been a great help for me.
Did you implement IHttpModule on your class (that is what contains the Init method and is what aspnet probably looks for)?
Hi, we have problem with users getting married or divorced thus changing their names. The AD login name is changed when a user changes name. When a user authenticates EPiServer looks for a Community user with the same user name as logged in identity. If no such user exists, EPi creates a new Community user.
So, a user that might have been very active in the Community gets a new login name for the same old AD account (identified by Guid), logs in and gets a new clean Community user. All the users former posts etc seems to be gone.
Does anyone have any experience solving this? I would like to know if I can override the code that finds/creates the Community user based on the login identity. Or is it possible when logged in with the newly created user to switch back to the old user, update the user name and delete the newly created Community user object?
Thank you in advance for any helpful advice :-)
/Josef