Cross scripting plague..

📦 Install & Upgrade Help
1

SuiteCRM put up quite a fight when I tried to install it on a host I have with an ISP.

I tried installing 7.2.1 Max. Target platform is BSD, my desktop is OSX 10.10.3

For a start, I had to create the main DB manually after which SuiteCRM did the rest, without that I couldn’t even get it started.

Post installation, I got several apparent “stalls” when trying to set up SuiteCRM using Safari. When I switched to Firefox I got a “Possible Cross Site Request Forgery (XSRF) Attack Detected” message, which explained why nothing worked (but doesn’t quite explain why this didn’t show in Safari). I applied the suggested changes to config_override.php.

When I re-checked that file after saving a setup, it turns out it had processed those changes into something like this:

$sugar_config[‘http_referer’][‘actions’][0] = ‘index’;
$sugar_config[‘http_referer’][‘actions’][1] = ‘ListView’;
$sugar_config[‘http_referer’][‘actions’][2] = ‘DetailView’;
$sugar_config[‘http_referer’][‘actions’][3] = ‘EditView’;
$sugar_config[‘http_referer’][‘actions’][4] = ‘oauth’;
$sugar_config[‘http_referer’][‘actions’][5] = ‘authorize’;
$sugar_config[‘http_referer’][‘actions’][6] = ‘Authenticate’;
$sugar_config[‘http_referer’][‘actions’][7] = ‘Login’;
$sugar_config[‘http_referer’][‘actions’][8] = ‘SupportPortal’;
$sugar_config[‘http_referer’][‘actions’][9] = ‘Save’;
$sugar_config[‘http_referer’][‘actions’][10] = ‘index’;
$sugar_config[‘http_referer’][‘actions’][11] = ‘ListView’;
$sugar_config[‘http_referer’][‘actions’][12] = ‘DetailView’;
$sugar_config[‘http_referer’][‘actions’][13] = ‘EditView’;
$sugar_config[‘http_referer’][‘actions’][14] = ‘oauth’;
$sugar_config[‘http_referer’][‘actions’][15] = ‘authorize’;
$sugar_config[‘http_referer’][‘actions’][16] = ‘Authenticate’;
$sugar_config[‘http_referer’][‘actions’][17] = ‘Login’;
$sugar_config[‘http_referer’][‘actions’][18] = ‘SupportPortal’;
$sugar_config[‘http_referer’][‘actions’][19] = ‘SaveConfig’;
$sugar_config[‘http_referer’][‘list’][0] = ‘test.xxxxxxxx.com’;

(xxx to protect the innocent).

The weird thing is that this is required on the actual host - the code IS on the “test.xxxxxxxx.com” host so I’m a bit confused why it thinks there is a cross scripting attack happening. The other annoying thing is that that [actions] array keeps expanding as I keep running into these alerts (note that that table already appears to have duplicates, yet it was a straight cut & paste from the cross scripting alert page)

Questions:

1 - is this a bug?
2 - if not, it needs a good workaround. Is there a way to just tell it to allow all actions from this host instead of slowly building up this list, otherwise this may happen again when it’s actually in production and I’m not around to fix it.

Now I know how I can convince it to install I’m going to nuke the current install (after preserving the carefully constructed config_override.php) and do it all again, but it would be nice not to have to worry about more trip ups.

On the plus side, the email setup worked pretty much from the word “go”.

Thanks in advance for any help.

EDIT: Update: I get this cross scripting attack alert for pretty much ANY action on the “admin” screen.

2

I have a bit of a self reply here - I have come across something that may explain things a bit. It appears that the cross scripting detection is overly sensitive to wildcard domain names. I had a setup on crm.domain2.com, but everything else on that domain is wildcarded to another domain1. Now I have set it up on crm.domain1.com I only get the “normal” errors, like all the buttons being labelled as “undefined” (post coming for that later).

I discovered this when I set it up on an empty test domain I have, and none of the usual problems appeared - it went straight in with only a few errors.

So it’s sort of fixed, but I’m leaving this as unaddressed as there has been no real identification of cause.