Forums (Obsolete)

Member

wtijsma - 3/30/2005 2:00:32 PM

REQ: Groups (for CommunityServer support)

Hi,

I'm pretty close to completing a Custom Membership/Profile/Role Provider for KenticoCMS to allow integration with CommunityServer (communityserver.org). It's pretty cool, I can manage KenticoCMS Users and Roles from the Community Server administration panel!

Anyway, since I've added all roles from CommunityServer as well, it's becoming a lot and a little difficult to handle. It might be nice to (especially because all our customers (1000+) are getting accounts as well) have groups that allow you to attach roles to, like the standard NT Users to make user management a little easier. I don't understand why it isn't in the Profile and Membership Management Application Block structure yet.

I understand this is a significant change to the system, but maybe something to think about.

Regards, Wiebe

p.s. Where did the Future Requests & Improvements forum go ? :-|


Guest	admin - 4/8/2005 2:15:23 PM Re: REQ: Groups (for CommunityServer support) Hi Wiebe, I'm sorry for the delay. Thank you for your suggestion. We will sure consider it for some major upgrade. We have removed the "Future Version Requests" forum together with other 1.0 Beta forums. I will create a new one instead. Best Regards,


Member	cpaul - 4/15/2005 4:43:04 PM Re: REQ: Groups (for CommunityServer support) Wiebe, I'm looking at integrating Kentico in with new version of an existing site with its own end user database already populated. Could you post any advice you have toward making the Kentico user/role system look to my other database?

Guest

admin - 4/15/2005 5:11:32 PM

Re: REQ: Groups (for CommunityServer support)

Hi Chip,

There are basically two ways:

1) You can create a synchronization SQL procedure that will periodically copy/update/delete all account information from the existing database to Kentico CMS database.

2) You can try to delete the tables CMS_User, CMS_Role and CMS_UserRole and create new views of the same name. The views must contain the same fields as the original tables, but you can take data from your existing database. You can find the detailed documentation of those tables in the Kentico CMS Database Reference (in the Start menu). I must admit we haven't tested this, but as far as you use those table for reading only, there shouldn't be any problem.

Should you need any help with that, please feel free to contact me.

Best Regards,

Member

wtijsma - 4/18/2005 9:29:34 AM

Re: REQ: Groups (for CommunityServer support)

Hi cpaul,

I've done the other way around, I've adapted the MemberRoles provider to support the KenticoCMS Tables, wich is easier. But I don't know where KenticoCMS is using the tables, because there's no real data layer.

Is the other system also SQL Server based?

The most important view, cms_tree_joined is currently dependent of the user tables, so you would also need to link your views to that one.

You wouldn't be able to use the CMSDesk Admin interface for user maintenance.

You would lose the easy possibility to upgrade.

The best would be if KenticoCMS would use the MemberRoles provider as well for authentication, or provide a abstract data layer that would allow you to implement your own one.

Currently there's no separation of layers at all (sql and business logic are even placed in aspx pages sometimes if you look at the CMSDesk), wich is too bad and will make it hard to customize the system.

Member

cpaul - 4/18/2005 4:20:24 PM

Re: REQ: Groups (for CommunityServer support)

The other system is on Sybase, but because it is our own website/ecommerce logon we have a bit more flexibility in the solution - I'm not adapting another third party product, so I can change the table around a little to help.

I'd really be okay with keeping the two things separate, as long as I could both let the content managers in to edit, and the customers in to order - just stored in different db's. But I don't think I can do that based on how the authentication stuff gets stored in the session, and the forms authentication section of the web.config.

I'm also considering breaking the cmsdesk out to its own application (like you've done) as that may make it easier to support two authentication schemes.

Member

wtijsma - 4/18/2005 4:46:05 PM

Re: REQ: Groups (for CommunityServer support)

Hi Chip,

In that case I'd be going with the synchronization scheme as suggested by Petr...

I've created a similar thing with our implementation, it syncs our customers and resellers CRM Databases from Lotus Notes (if you can call that databases) adds a profile (using the Membership Application Block) and copies their usernames and passwords to kenticoCMS. It works, but it's hard to manage them using CMSDesk now, so I've created a different application for that.

Member

cpaul - 4/19/2005 6:23:31 PM

Re: REQ: Groups (for CommunityServer support)

What about rewriting the user/security/auth portion and not using any of the built in asp stuff, thus keeping CMS login and user website login separate?

It seems ridiculous to copy thousands of customer logins into the CMS tables, when we'll only have 3 or 4 CMS users. And I'll have no users that need BOTH cms access and access to the secured areas on the site.

What about breaking the app into two separate CMSDesk + Website apps, and each does it's own authentication?

Considering they want me to add forums, and most forum integrations I've seen suggest storing a duplicate login database, I don't really want to have three copies lying around.

Perhaps in a later version, Kentico could bypass the std ASP authentication scheme, so that it wouldn't get in the way of the site you are trying to put under CMS?


Member	wtijsma - 4/20/2005 9:24:27 AM Re: REQ: Groups (for CommunityServer support) Hi Chip, I didn't realize your didn't need to integrate anything, in that case I think it's best to put every application in it's own IIS application, including CMSDesk. That should keep everything separate and kentico be able to use the standard authentication scheme. Wiebe

Member

cpaul - 5/11/2005 6:00:42 PM

Re: REQ: Groups (for CommunityServer support)

Will that break the "Site" tab that shows the site with the edit buttons? Are there any tricks to pulling the CMSDesk out, or can I literally move the /cmsdesk off into it's own application and have anything work?

I guess after they are separate I continue to authenticate my users as always, and the Kentico application handles it's stuff the built-in way, and never the two shall meet?


Member	wtijsma - 5/12/2005 9:49:09 AM Re: REQ: Groups (for CommunityServer support) Hi, I think the site still expects the CMSDesk to be in /[sitename]/CMSDesk. If you just give CMSDesk it's own application, it should work, and nothing get's broken. I haven't tried moving the CMSDesk out of the site root, but theoretically it should work by just changing the web.config paths.

Guest

admin - 5/12/2005 10:12:14 AM

Re: REQ: Groups (for CommunityServer support)

Hi Chip,

It's generally possible to have Kentico CMS Desk in another folder (we actually do that during the development). However, you will need to modify the paths in the web.config file (CMSMetadataFolder, CMSFilesFolder). If you create a virtual application on the top of CMS Desk, you may need to make some minor changes in the CMS Desk code - please find all occurences of "~/cmsdesk" and replace them appropriately.

Should you need any help with that, please feel free to contact me.

Best Regards,

Member

cpaul - 5/20/2005 10:40:30 PM

Re: REQ: Groups (for CommunityServer support)

Having the CMSDesk under the site root is not a problem, as long as the two applications maintain separate authentication.

Can you tell me if this is the right method to do this?

Copy the CMSDesk portion of the project to a separate project under the solution.
Configure new cmsdesk project to deploy as /site/cmsdesk
Move relevant portions of Global.asax.cs and web.config to the new CMSDesk project.
Implement new authentication in Global and web.config specific to my application

Am I making this way more difficult than it should be?

Thanks for all the information Wiebe & Petr

Member

wtijsma - 5/23/2005 2:59:00 PM

Re: REQ: Groups (for CommunityServer support)

Hi Chip,

you don't have to physically move the cmsdesk_cs folder under your application folder, you only have to create a virtual directory [mywebsite]/cmsdesk ) in IIS pointing to the CMSDesk_CS folder.

Also today I discovered a bug if your CMSDesk runs in a seperate application, and your website runs on the root of the website (www.mydomain.com/ and www.mydomain.com/cmsdesk), because in this case the friendly url's don't get created properly (they are created like this: www.mydomain.com/cmsdesk/[aliaspath] instead of www.mydomain.com/[aliaspath], so I had to change the 'Functions.cs' class in the CMSDesk (not a real descriptive name by the way, goes pretty much agains every rule in OO).

But generally, I think you're going the right way ;-)


Member	cpaul - 5/26/2005 4:57:55 PM Re: REQ: Groups (for CommunityServer support) That is related (or identical) to the bug you posted <a href="http://www.kentico.com/Forums/ShowPost.aspx?PostID=331">here</a> ?


Member	wtijsma - 5/28/2005 3:13:18 PM Re: REQ: Groups (for CommunityServer support) yes... I modified the CMSDesk (Function.cs) source code to fix it.


Guest	admin - 6/8/2005 6:42:48 PM Re: REQ: Groups (for CommunityServer support) Hi Wiebe, I just wanted to mention that the friendly URLs are created at the path that you specify in the CMSWebApplicationVirtualPath parameter in the web.config file ("/" for web site root). We use this in our development environment and it works very well. Best Regards,


Member	wtijsma - 6/9/2005 12:38:55 PM Re: REQ: Groups (for CommunityServer support) Hmm, could be, I had trouble specifying a "/" as site root, especially with created links. Maybe I did something wrong.

Member

lucasrem - 7/15/2005 8:04:51 AM

Re: REQ: Groups (for CommunityServer support)

please keep focus on our original idea, i know things changed, you still develop the controls, but what about the the rest, css and what about the activeX controles.

would be great to finish my stuff too, is there still a way to work this out, Kentiko is not the solution we both know that, thats what you whanted it to be.
i will contiue with the original idea of the CMS basics, stip will be my next thing to contiue with our original ideas, what started with gerels project in amsterdam.

togetter we make great things

lucas rem
www.netindustry.nl