I had to add this fix for a new Community Server site launch this fine Super Bowl Sunday so I thought I might as well blog about it. It's also an important issue when using Community Server Single Sign-On.
Single Sign-On automatically creates new user accounts in a Community Server community with the primary membership stored in another application and data source, typically a parent ASPNET site. This works great, but emails are created as [username] + @localhost.com, or daveburke@localhost.com.
What problem might this produce on the community site? Quickly now...Correct! Site-specific email functions are hosed. This means when using a Single Sign-On configuration with Community Server you want to reproduce the user email addresses from the main membership data source in the site’s ASPNET_Membership and cs_users tables.
One way to achieve this is creating a CSModule to update the email addresses when an account is created in the child community site. The module itself is very simple and looks like this.
Hidden in the simplicity of the module is a requirement of a second Data Provider for the main membership data source. You can see how the email is obtained from the originating data source from the provider I named "HomeDataProvider" then passed to a local stored procedure with the "DRIVEDataProvider."
The good news is that if you're using the Drive Framework, the HomeDataProvider classes are generated for you, as is the code to retrieve and update the code in the two databases with one of Drive’s Composite CodeSmith Templates. The DRIVEUsers.cs class and CreateDRIVEUser CSModule are included in the Drive Project Setup templates, so most of the work there is done as well. Then all we have to do is update the communityserver_override.config, add the connection string in connectionstring.config, upload the fresh DLLs, and bill the client your Super Bowl Sunday hourly rate.