server config + advanced search tasks = broken due to long fieldname

[Eileen]

I have found that one of our servers we are seeing the code that selects contributions etc from advanced search appears to be broken. Contacts are not selected & I think the reason is simply they tend to have less digits.

What I'm seeing is the url to calculate the number looks like

http://mysite/civicrm/ajax/markSelection?qfKey=civicrm+search+11e4a89dfef8e35ee0539400db5bd869_6620&name=mark_x_91755-mark_x_12536-mark_x_130856-mark_x_12536-mark_x_99898-mark_x_89349-mark_x_68159-mark_x_53162-mark_x_29747-mark_x_7994-mark_x_24825-mark_x_130383-mark_x_103756-mark_x_4227-mark_x_117297-mark_x_130856-mark_x_131220-mark_x_131966-mark_x_131577-mark_x_68082-mark_x_67965-mark_x_130748-mark_x_132153-mark_x_120763-mark_x_132788-mark_x_4738-mark_x_132809-mark_x_72916-mark_x_131900-mark_x_51423-mark_x_12008-mark_x_21061-mark_x_121893-mark_x_87447-mark_x_88075-mark_x_47532-mark_x_27-mark_x_133929&variableType=multiple

& once the name field goes over 512 characters the whole thing breaks & the field values don't actually reach the relevant function.

In the short-term I need to figure out the server setting to change.

In the longer term maybe Mr Unassigned would think about changing mark_x_ to something shorter so it's harder to break this

[Eileen]

The key server difference seems to be whether the whole site is under https (it is on nginx too). I tried on civicrm.org (which is on https) & the number NEVER shows - which is different again (demo is not on https)

[Eileen]

Actually - mis-test on civicrm.org - I was doing from contribution search - needs to  be from advanced search.

So, demo - not on https - if I add a whole lot of digits to the 'name' field ie query url becomes

http://drupal.demo.civicrm.org/civicrm/ajax/markSelection?qfKey=civicrm+search+bc88bdceaf9fe7e35fd106723454edea_6307&name=mark_x_37777778888888888888888888888888888888888777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777778-mark_x_81-mark_x_86-mark_x_4-mark_x_71-mark_x_60-mark_x_8-mark_x_64-mark_x_139-mark_x_95-mark_x_117-mark_x_18-mark_x_184-mark_x_22-mark_x_3-mark_x_82-mark_x_185-mark_x_67-mark_x_114-mark_x_153-mark_x_148-mark_x_110-mark_x_106-mark_x_181-mark_x_203-mark_x_92-mark_x_138-mark_x_192-mark_x_150-mark_x_231-mark_x_160-mark_x_201-mark_x_100-mark_x_89-mark_x_136-mark_x_129-mark_x_188-mark_x_193-mark_x_17-mark_x_23-mark_x_164-mark_x_178-mark_x_245-mark_x_179-mark_x_122-mark_x_79-mark_x_46-mark_x_73-mark_x_200-mark_x_77&variableType=multiple

CiviCRM.org results in an error if I do the same which is the same as I get on my site. Because most of the contribution ids on my site are 6 digits long I don't need to bump up the field length to get an error. But, I'm consistently seeing that https sites are getting upset about excessive field length

[Eileen]

Ok - so I'm seeing this consistently in databases with large numbers for contact ids - ie. because 50 * 2 = 100 so if ids are like 50000 vs 500 then the string is 100 chars longer so higher chance of the field being more than 512 char

[Eileen]

Ah - bgm suggested sushosin is deprecated - but it IS on the server

suhosin.get.max_value_length => 512 => 512

[Chris Burgess]

Yep, this default Suhosin config will stop a bunch of things working - also frequently affected are IPN responses, since they tend to have larger query strings.

In Suhosin config (prob /etc/php5/conf.d/suhosin.ini),

Code: [Select]

suhosin.get.max_value_length = 8192


[mathieu]

Ah, I didn't know about the context, I saw the question on IRC while I was not at my computer, and the 512 seemed suspicious.
Suhosin was dropped from Debian wheezy (PHP 5.4), but the CiviCRM servers run Ubuntu (and probably some older LTS version with PHP 5.3).

More info on Suhosin deprecation is documented on Wikipedia:
http://en.wikipedia.org/wiki/Suhosin

In a tangential note, PHP 5.4 and 5.5 bring a bunch of memory/performance improvements, I strongly recommend it