The ongoing debate and question continues… However, as of late, some breakthroughs on my end in this area.
Basically, with a little bit of tweaking, hacking, cheating, and fooling, AspDotNetStorefront (ASPDNSF) and Community Server (CS) can live happily ever after in a single user session and “share” user account information.
And now, for the approach… In broad strokes:
1. Setup ASPDNSF and CS in their own virtual Webs within the same domain (e.g. domain.com/community, domain.com/store/)
2. Set both ASPDNSF and CS Web.config machine keys and cookie names to be identical.
3. Modify ASPDNSF code where it reads/writes to the cookie to reference the new shared name.
4. Add a column in ASPDNSF customer table that stores the CS user name (so when a user account is created on CS it will create a user account in ASPDNSF with a matching user name)
5. Modify ASPDNSF code where it reads cookie to pickup the user name (since CS will write the user name to the cookie and not a ASPDNSF GUID as ASPDNSF normally does out of box), then using that user name lookup ASPDNSF’s customer GUID in the DB and reference that for the ASPDNSF session.
6. Locate all locations in stored procedures that create/update user accounts to handle the new CS user name column.
This will ultimately allow you to sign into CS, then go to domain.com/store/ and get automatically signed into ASPDNSF since the cookie already has your sign-in information and a matching session record is located in ASPDNSF’s database.
As for the rest of the details – specific code changes, stored procedures etc., more details to come later when time permits.
Finally, since CS and ASPDNSF have URL re-writing engines we can elegantly handle those elaborate URL’s so things look nice and clean when a user view’s a ASPDNSF page and a CS page.
Hope that helps with some people out there… Enjoy!
