If we already have a web site utilizing the asp.net 2.0 membership features, will we be able to "plug in" CS2007 and have it use our existing user schema? Or will it be hard to integrate into an existing asp.net 2.0 web site?
Thanks,
Kmac
Hi Kmac,
This is one of the scenarios that Morpheus (our recent membership work) is designed for. You should have a couple options:
Since Morpheus breaks the database ties between CS and ASP.NET Membership, you can now tell Community Server to use a different database for membership related work. To enable this just follow these steps:
This last step is not optional. With Morpheus we've wrapped the default ASP.NET providers with some bulk "get" support that requires some new stored procedures exist in the membership store. Since, by default, Community Server assumes a single location for your site + membership, we haven't broken these sprocs out into a separate file. Below is the list of sprocs that should be run in your membership database:
Finally, Morpheus also enables two CS installations (CS2k7+) to share the same membership. In this case, you wouldn't need to run the sprocs above as both installations would already have them as part of a CS 2007 install.
Hope this helps...
One is glad to be of service...
Does this mean that the (extra cost) single-sign on ASP.NET membership provider add-on is no longer required with CS2007?
Jose Lema: Add a new connection string pointing to your membership (existing site) database Update your providers (Membership, Profile, and/or Role) to use the new connection string Run a few sprocs in your Membership Database which allow CS to access Membership data in a way that is more performant This last step is not optional. With Morpheus we've wrapped the default ASP.NET providers with some bulk "get" support that requires some new stored procedures exist in the membership store. Since, by default, Community Server assumes a single location for your site + membership, we haven't broken these sprocs out into a separate file. Below is the list of sprocs that should be run in your membership database: cs_Membership_GetUsersByName cs_Membership_IsUserNameTaken cs_Membership_RenameUser cs_Membership_ChangePasswordAnswer cs_Membership_ValidatePasswordAnswer cs_Profile_GetPropertiesForUsers cs_Role_Get cs_Roles_CreateRole cs_Roles_UpdateRole cs_Roles_GetRoleIdsForUsers cs_Roles_Get
That list of sprocs we just need to run once in that order ?
I've tried doing this with a fresh install of CS 2007 Beta 1, and am running into some issues (i.e. it doesn't work). Here are the steps I followed:
At this point, everything breaks. Attempting to view any page on the CS2007 instance results in an exception: "System.Exception: A null MembershipUser is not valid to instantiate a new User".I'm sure that I'm missing something. We're looking to break the membership out to our membership database, leave roles in the CS database, and split profiling across the two.
Any thoughts?
- Kyle (and the officialCOMMUNITY Team)
Yeah I guess Im in the same spot. I have a cs2007 beta instance up and running changed the connection string to hit my existing memebership tables and updated the membership/profile/roles providers, but I think im stuck at the last step. Especially when I look at cs_Membership_GetUsersByName, the proc wants a username(s) for the second param.
I guess my question is do I have to run that list of procs for every user that already exists ?
Is there a script already to do this? or more documentation anywhere ?
mcbeev: I guess my question is do I have to run that list of procs for every user that already exists ?
I think Jose just means that those sprocs need to be created in your membership database.
officialcommunity: At this point, everything breaks. Attempting to view any page on the CS2007 instance results in an exception: "System.Exception: A null MembershipUser is not valid to instantiate a new User".I'm sure that I'm missing something. We're looking to break the membership out to our membership database, leave roles in the CS database, and split profiling across the two.
Hi Kyle,
The likely issue is that you created a new user in your CS install that doesn't exist in your membership database. The first-time use can be a bit tricky, especially if you're starting from a clean system. You'll need to be sure that your application names match and that the user you login to CS with actually exists in your membership database (strictly from a username/password viewpoint).
Let me know if that solves the problem...
Hi mcbeev,
My notes were regarding having a separate membership database. If CS and your membership are stored in the same database, then you shouldn't have to do much configuration. Just make sure that when you create your community (ala cs_system_createcommunity), you use the sample application name as your membership data store.
Hope that helps...
Jose Lema:Hi Kyle, The likely issue is that you created a new user in your CS install that doesn't exist in your membership database. The first-time use can be a bit tricky, especially if you're starting from a clean system. You'll need to be sure that your application names match and that the user you login to CS with actually exists in your membership database (strictly from a username/password viewpoint). Let me know if that solves the problem...
Thanks Jose, that seems to have done the trick.
Cheers,
-Kyle
Hi Jose,
I have another question about Morpheus and membership integration.
We're currently running CS 2.0 and have it integrated with our own single sign-on provider (using the ASP.NET provider model). Due to the constraints of CS 2.0, this means having two membership providers defined in the web.config. Also, when creating a new single sign-on account, we have to manually create the CSUser for everything to flow smoothly.
This is a messy solution. What we'd like is to be able to tack our membership provider onto the front end of CS 2007, without having to touch CS, its database, or use the CSMembershipProvider, but it looks like there might still be ties in place. Ideally, we'd like to have the freedom to create our membership provider backing onto MSAccess, and still have it plug in seamlessly to CS (not that we'd ever do anything horrible like that, of course).
I've tried upgrading one of our CS 2.0 sites to 2007. Our single sign-on membership provider is the only one defined in the web.config, application names match in the two databases, and users exist in both databases (including Anonymous and admin users). However, when I try to open the site, I get the error: "Unable to cast object of type 'OfficialCommunity.Security.CommunityMembershipProvider' to type CommunityServer.ASPNet20MemberRole.CSMembershipProvider'."
Could there be something I'm missing that could cause this (maybe there's something else that needs to be done to migrate the site)? Or is CS 2007 still tied to the CSMembershipProvider?
Thanks for the question.
Since Beta 1 of CS2k7, we've made some tweaks to Morpheus. One of those tweaks directly addresses the issue you raise. The reason for the cast is that we're trying to execute some sql within the context of your database (which is unknown to us). So, since the ASP.NET membership provider does not support a method to get users in bulk, we defer the call to a provided method but we need to execute it in the context of your membership store. Now, unfortunately, we have *no idea* where your membership store is. And due to medium trust issues, we cannot get to the connectionStringName from the provider entry in web.config. As a result, we need to cast your provider to some known interface to get the appropriate connectionStringName. Since that was the only thing we used the cast for, we've created an IConnectionStringName interface that your provider must implement.
Currently in Beta 1, you'll need your provider to subclass CSMembershipProvider, but in our next Beta, just implementing this simple interface should do the trick.
Does that help?
Copyright© 2008 Telligent Systems Inc. All rights reserved CommunityServer.com • Telligent.com