URGENT:Issue with Cookie Paths [Bug?]

[computerology]

We have two separate databases of SugarCRM running on the same server.

A serious problem has occurred when a user opens one database and then the other. Investigation has revealed that it has something to do with the cookie tracking the sortation of the views.

For some reason the cookie or session keeps track of the sortation field in the previous database (or other browser window of the DB). It then tries to do a sortation based on this cookie, and the window dies because the field does not exist.

The problem was quickly and temporarily rectified by adding in a dummy field matching the name of the field in the other database. It had nothing to do with the list view configuration of either database, and upon testing by trying to open both databases at the same time (on the same server) the program was duplicated in the opposite direction.

The problem effects every list view with sortation ability.

I found information here about changing the session_dir variable - however this merely broke the login! Perhaps there is something I am doing wrong, but I tried changing the session dir to the database's name to try to separate them. The cookie shows up on the client side browser named nothing but the IP address. I also tried changing the unique ID but that had no effect whatsoever.

The proper solution to the problem would be to be able to rename the cookie on the client side (?) so the browser doesnt get the two mixed up (?) or alternatively have something server side changed so that the browser does not try to tell Sugar to sort a listview like it was done in the other database (comes up cannot find column, etc as the field does not exist).

Any ideas would be very much appreciated.

[computerology]

Ok so I have told save_query = 'none' this should probably clear the error but I am not sure if it will do anything for the sortation fields which is what was breaking the listviews.

I have tried creating directories in the php/tmp for the session_dir but each time I do this it breaks the login and sugarcrm is useless. It is a Server 2003 install and i even doublechecked the permissions on the TMP directory in PHP and forced them downline to update the new folders I had created for the new session dirs.

I do not see a session file even appear in the new directories but once I hit the login page with everything to default it appears in the tmp folder so I know I'm looking in the right place. I tried all sorts of slash combinations, no slash, trailing and preceeding to no avail.

[kbrill]

I take it that both your installs, while pointing at different databases, share the same domain? Like www.crm.com/crm and www.crm.com/crm2?

[computerology]

I take it that both your installs, while pointing at different databases, share the same domain? Like www.crm.com/crm and www.crm.com/crm2?

yes. They are using the same IP yes in different subfolders just as specified.= above- although it is an IP and not a domain

I checked the browser side cookie - and it only reads the IP address as the name of the cookie. If I could rename the cookie that would fix one side to the problem (users getting carryovers from one db to the other for sortation preferences). The other side to the problem is with the sessions - I've tried creating the folders in the php/tmp for each database but whenever i specify in config.php to use those folders for sessions the login no longer works with any password.

Halp

[kbrill]

yes. They are using the same IP yes in different subfolders just as specified.= above- although it is an IP and not a domain

I checked the browser side cookie - and it only reads the IP address as the name of the cookie. If I could rename the cookie that would fix one side to the problem (users getting carryovers from one db to the other for sortation preferences). The other side to the problem is with the sessions - I've tried creating the folders in the php/tmp for each database but whenever i specify in config.php to use those folders for sessions the login no longer works with any password.

Halp

coockies are attached to domains or in your case ip addess (as you are using the ip address as a domain). It's the same if you have www.crm.com/crm1 and www.crm.com/crm2. the cookies are all attached to www.crm.com not matter what SugarCRM says.

And I think the session path in the config.php must match the session path in your php.ini file. You can't (AFAIK) have multiple session paths. I didn't look that up so the may be some configuration where you can run seperate php.ini's under one apache but I don't know about it.

You need to set up virtual name based domains on your server so each instance of SugarCRM has it's own domain name.

[computerology]

coockies are attached to domains or in your case ip addess (as you are using the ip address as a domain). It's the same if you have www.crm.com/crm1 and www.crm.com/crm2. the cookies are all attached to www.crm.com not matter what SugarCRM says.

And I think the session path in the config.php must match the session path in your php.ini file. You can't (AFAIK) have multiple session paths. I didn't look that up so the may be some configuration where you can run seperate php.ini's under one apache but I don't know about it.

You need to set up virtual name based domains on your server so each instance of SugarCRM has it's own domain name.

While I do know of a route where multiple php.ini's are able to be run under one apache, it's somewhat of an advanced setup normally used by hosting companies (if there's a php.ini in the current folder, it uses that one, otherwise it uses the default).

Setting up virtual name based domains on the server is a bit extreme to fix an issue with cookies - and in this particular case it's impossible. The customer has this draconian ISP that while he gets 10Mbit up/down on fibre he can't control his own static IP (it trunks at the ISPs router, we have to get the ISP guy to set up port forwards and beleive me that was enough of a nightmare enough to get sugar working behind that kind of hokey solution. (note to Toronto people... SPGGlobal is a draconian ISP.-- the cable company provides more flexible service to my house than these guys) So... setting up even more than one static at this location is probably not going to work out at all, let alone getting two domains and updating A and MX records for those statics.

However these solutions while I'm sure they will work are a bit extreme, there must be a place somewhere where I can change the cookie name in the source in a few minutes. I haven't identified that the sessions themselves are the culprit, but more likely the cookies at the user end because the problems experienced are user and machine specific, carrying the sortation from one database to the other and the like. I find it somewhat odd that SugarCRM doesnt specify in the install what to name the cookies - even old XOOPS and PHPNuke loads allowed you to give the cookie a name specific to that install.

Anyone know what the file with the cookie creation source is?

[computerology]

Come on.

This is a legitimate bug, why does the thread go dead? Not only is this a legitimate bug but it's also a simple bug to fix - change the cookie's name in the config.php for each DB if you are running multiple SugarCRMs on the same domain!

This is the second time this has happened to me. Two SugarCRMs customized with different fields for different databases is a legitimate use of SugarCRM Open Source.

Why the developers fall silent when I want to change something as simple as a cookie label is suspect. It's as simple as changing a variable for the cookie name, which should have even been included in the installer.

[kbrill]

Come on.

This is a legitimate bug, why does the thread go dead? Not only is this a legitimate bug but it's also a simple bug to fix - change the cookie's name in the config.php for each DB if you are running multiple SugarCRMs on the same domain!

This is the second time this has happened to me. Two SugarCRMs customized with different fields for different databases is a legitimate use of SugarCRM Open Source.

Why the developers fall silent when I want to change something as simple as a cookie label is suspect. It's as simple as changing a variable for the cookie name, which should have even been included in the installer.

I'm no cookie guru as I've never had to find a workaround, but what about things that can't be renamed (AFAIK) like $_COOKIE['PHPSESSID']? I may be wrong there, never really had to research it.

But another point, if my SugarCRM install was important to my business I might spend more to get a real host. Many of the support EMails I get are trying to get one $10 host or another working for Sugar. Your renaming the cookie idea may be a good one but there is no substitute for the right host.

[jeffjw]

P R O B L E M !

You have multiple SugarCRM's installed on the same directory.

http://www.mydomain.com/sugarcrm1/
http://www.mydomain.com/sugarcrm2/

The session cookies conflict. The config.php probably needs a few more variables. Hint hint Sugar CRM team.


S O L U T I O N !


includes/entryPoint.php

Search for setPhpIniSettings(); around line 88.
Insert following below it.

// JJW - Custom Session Parameters
$jjw_dir_parts = explode('/', getcwd());
$jjw_session_cookie_path_dir = '/'.$jjw_dir_parts[count($jjw_dir_parts)-1].'/';
session_set_cookie_params(0, $jjw_session_cookie_path_dir);

This will set the session cookie directory path parameter; example: '/sugarcrm1/'. This will restrict the cookie to only be used within the scope of that Web directory.

You could also write it into the utlils.php - setPhpIniSettings() function using ini sets, but this will work.

Open your main index.php script
Change all of your instances of setcookie() to include the new directory paramater.

~ Line 135
setcookie('PHPSESSID', '', time()-42000, $jjw_session_cookie_path_dir);
~ Line 495
setcookie('ck_login_id_20', $_SESSION['authenticated_user_id'], time() + 86400 * 90, $jjw_session_cookie_path_dir);
~ Line 499
setcookie('ck_login_theme_20', $_SESSION['authenticated_user_theme'], time() + 86400 * 90, jjw_session_cookie_path_dir);
~ Line 503
setcookie('ck_login_language_20', $_SESSION['authenticated_user_language'], time() + 86400 * 90, $jjw_session_cookie_path_dir);

Sorry if something didn't make sense. This is the second time I wrote this and I'm sick with Cat Scratch Fever (really...).

Cheers,
Jeff Walters