I finally discovered the impact of SUHOSIN after six months of trying to track down why several popular modules wouldn't work when uploaded to a hosted server. They worked OK on a development set-up (Windows XP) but failed on a hosted Linux server.

The modes of failure on the server were unhelpful which made troubleshooting complicated. In some instances it returned a simple 'server error' page, and in the server log it just said something about 'incomplete headers'. In other instances the attempt at updating permissions seemed to complete OK but the permissions hadn't actually been updated.

What I believe was happening was that SUHOSIN just cut off the posted data after reaching its set limit. When that messed up an array within the $_POST, say by letting an 'index' variable through but not its associated 'value' variable, then I got an error page, but if the data in the $_POST was still a valid collection (albeit with some missing) then the process continued but some expected updates didn't get done!

Before realizing that SUHOSIN was the culprit I spent some time trying to replicate my host's environment on the XP machine. Dumped IIS and installed a WAMP set up, changed the Apache version, changed the MySql version, changed the PHP version, changed from PHP as a module to fast-cgi, and finally changed all the php.ini settings to match those on the host (well those I could understand anyway!).

The thing that stumped me was getting SUHOSIN itself. Over at its home (Hardened php project) it's downloadable as a set of files that need compiling. I guess that's something Linux users are good at but for inadequates like me it has to be a dll file. Links around the Internet pointed to the forums area at SUHOSIN's home as a place to get the dll but it seemed to be permanently in 'maintenance' mode (still is today). I eventually found one, but unfortunately I can't remember where and recent attempts at searching hasn't turned it up a second time. If someone knows where this can be downloaded I'm sure others would benefit. Alternatively, if anyone can offer download space then email me at support.xoops.forums@origma.demon.co.uk and I can send a copy.

To continue ...
Once installed on the WAMP set up SUHOSIN is quite easy to experiment with. When it catches something it writes an error report to XP's Event Viewer saying what happened. Also you can put it into 'simulation' mode where it reports any breaches but lets the processing continue. All the parameters are set in php.ini so troubleshooting can be easy and quick. However if you are working in an IDE like Eclipse it will conflict with the debugger which is a shame.

After playing with it for a while I was able to work out what value I needed for the maximum variables in $_POST parameter. My site had 46 groups (yes yes I know it's a lot!) and I wanted to add new fields to the User Profile module bringing them to a total of 30. This meant I needed a value of 2852 (from 46 x 30 x 2). The hosting provider had already viewed the default figure of 200 too low and had doubled it to 400. But this was a little short of the figure I needed.

In discussion with them they raised the value to 1024 but pointed out the whole point of the restriction was to protect the server so were reluctant to simply whack the figure up just because I asked. Their position went something like, 'if the guy that wrote this stuff thought 200 a safe number to use then five times that number is probably as far as we want to go'. Quite reasonable really, they've bought into SUHOSIN to give them protection so it makes no sense to open it up and risk the bad boys getting in.

At the moment I have changed the management arrangements of the site along with several module hacks and reduced the groups to a bare minimum of 23 and ambitions for the User profile module have been reduced by restricting the field count to 26. This would need a $_POST variables limit of 1196 and I have re-approached the provider hoping that this modest change will be acceptable.

I hope my story will help others running sites, and indicate an area where the core, and module, developers might like to look at. SUHOSIN isn't going away.

SUHOSIN is a PHP extension from the Hardened PHP Project. Its purpose is to protect the server from various attacks. It is becoming popular among hosting providers. One its techniques is to limit the number of variables in $_POST, $_GET and $_REQUEST.

Xoops puts lots of variables in $_POST when modules update group permissions (groupperm.php). For example in User Profile, that comes optional with the core, on each of the 21 standard fields 'editable from profile' can be set Yes or No for each group.

With a standard install of SUHOSIN the permissions tab in User Profile will not work with more than four groups - yes FOUR groups!

Here's why. SUHOSIN's default limit for the maximum number of variables in $_POST is 200. It seems to count both the 'index' and 'value' bits within $_POST as separate variables so updating the permissions in User Profile with four groups results in 4 x 21 x 2 = 168 and with five groups it's 210. So with more than four groups and it fails.

This problem will also show up when updating a single category/topic/item within a module where you have lots of groups. For example in the News module, submit, approve and view permissions are set in each topic so here you are limited to 33 groups (33 x 3 x 2 = 198). This might sound like a lot of groups but with XOOPS modules offering fine-grained control over their categories/topics a site with several modules can easily exceed this. Groups are good and add power to the system.

Can the core team include in their 'standard requirements/recommendations' a maximum number of variables that can be handled by the post method?

If we had that then site admins can negotiate with the host providers, or set there own servers up in the comfort of knowing how ever many groups or category/topics they create they won't suddenly find the site failing.

Full story in next post ...

Hear! Hear!
I frequently copy my live sites to a local development machine and have to run sql updates on the database to change all the 'full' urls to their localhost equivalents.

Any help here would be useful.

Ghia - you pointed me in the right direction!

All this time it was the Suhosin PHP extension causing the trouble quietly working away on my hosted site restricting the number of POSTed variables to 400 and without logging anything anywhere when it caught a script exceeding it.

Getting a windows dll version of Suhosin took some time (already forgot where I found it - not very helpful, sorry) but now at least know what to do.

By the way Suhosin default setting for max POSTed variables is 200. This will prevent sites with only 5 groups setting permissions in the User Profile module as that has 21 fields that it grants permissions on, and POSTs it as an array where each 'variable' seems to be counted twice by Suhosin (5 x 21 x 2 = 210).

My hosting people have reluctantly increased their setting to 1024 and I have reduced my groups count down from 46 to 26 needing a setting of 1092 so I have still some work, or negotiation, to do.

But to get this far, after so long, is a great feeling and I do appreciate Ghia's help in sticking with me.
Thanks a lot!

Thanks Ghia for staying with me on this.

Quote: .. and the extra bit for testing ...
Quote: both correct

Quote: same in both

Did a file difference of source when displaying /modules/profile/admin/permissions.php?op=edit at host and at local. Apart from hostname in the action parameter there were no differences.

I'll re-check the phpinfo() stuff, and look into the Apache Sushin section (something I'm not familiar with). I will be so glad if we can resolve this!

This issue seems to be caused by some, but only some, variables not turning up in the '$_POST' array on a live site, whereas they do on a local setup.

As far as I can see the two setups are almost the same (details in earlier post).

If this is a server setup issue I would value any advice I could pass on to my provider.


Here's some more input to this issue.

Extended Profile module
***********************
Module Admin > permissions (url is now xx../modules/profile/admin/permissions.php)
This gives a big table of check boxes with a submit button. Hit the button and it takes you to:

xx../modules/system/admin/groupperm.php

This takes the posted variables and:
- checks which module you're updating
- checks the user has admin rights

If it likes the module and user it proceeds with the update, shows what it's updating and then returns to the page with the big table.

If it doesn't like the module or user it re-directs to a 'Sorry you don't have permission to access ..' page, which in turn re-directs to the front page.

In my case the local machine (details in earlier post) updates as expected, but on the hosted site it fails because some variables aren't posted.

I trapped the posted variables by adding into xx/modules/system/admin/groupperm.php these two lines at the top of the file:

print_r ($_POST); // shows what variables are posted
exit(); // stops further processing

Then hit submit on the Profile permissions page to see what got posted.

Local machine:
-------------
Array ( [perms] => Array ( [profile_edit] => Array ( [groups] => Array ( [1] => Array ( [1] => 1 [8] => 1 [12] => 1 [20] => 1 [2] => 1 [9] => 1 [13] => 1 [3] => 1 [10] => 1 [14] => 1 [22] => 1 [4] => 1 [11] => 1 [15] => 1 [5] => 1 [16] => 1 [24] => 1 [6] => 1 [17] => 1 [18] => 1 [19] => 1 ) [2] => Array ( [1] => 1 [8] => 1 [12] => 1 [20] => 1 [2] => 1 [9] => 1 [13] => 1 [3] => 1 [10] => 1 [14] => 1 [4] => 1 [11] => 1 [15] => 1 [5] => 1 [16] => 1 [24] => 1 [6] => 1 [17] => 1 [18] => 1 [19] => 1 ) ) [parents] => Array ( [1] => [8] => [12] => [20] => [2] => [9] => [13] => [3] => [10] => [14] => [22] => [4] => [11] => [15] => [5] => [16] => [24] => [6] => [17] => [18] => [19] => )
[itemname] => Array ( [1] => Real Name [8] => ICQ [12] => Allow other users to v... [20] => Website [2] => Location [9] => AIM [13] => Always attach my signa... [3] => Time Zone [10] => YIM [14] => Receive occasional ema... [22] => Rank [4] => Occupation [11] => MSNM [15] => Theme [5] => Interest [16] => Comments Display Mode [24] => Signature [6] => Extra Info [17] => Comments Sort Order [18] => Default Notification Mode [19] => Notification Method Wh... ) ) ) [submit] => Submit [modid] => 20 [redirect_url] => admin/permissions.php )

Hosted site:
------------
Array ( [perms] => Array ( [profile_edit] => Array ( [groups] => Array ( [1] => Array ( [1] => 1 [8] => 1 [12] => 1 [20] => 1 [2] => 1 [9] => 1 [13] => 1 [3] => 1 [10] => 1 [14] => 1 [22] => 1 [4] => 1 [11] => 1 [15] => 1 [5] => 1 [16] => 1 [24] => 1 [6] => 1 [17] => 1 [18] => 1 [19] => 1 ) [2] => Array ( [1] => 1 [8] => 1 [12] => 1 [20] => 1 [2] => 1 [9] => 1 [13] => 1 [3] => 1 [10] => 1 [14] => 1 [4] => 1 [11] => 1 [15] => 1 [5] => 1 [16] => 1 [24] => 1 [6] => 1 [17] => 1 [18] => 1 [19] => 1 ) ) [parents] => Array ( [1] => [8] => [12] => [20] => [2] => [9] => [13] => [3] => [10] => [14] => [22] => [4] => [11] => [15] => [5] => [16] => [24] => [6] => [17] => [18] => [19] => )
[itemname] => Array ( [1] => Real Name [8] => ICQ [12] => Allow other users to v... [20] => Website [2] => Location [9] => AIM [13] => Always attach my signa... [3] => Time Zone [10] => YIM [14] => Receive occasional ema... [22] => Rank [4] => Occupation [11] => MSNM [15] => Theme [5] => Interest [16] => Comments Display Mode [24] => Signature [6] => Extra Info [17] => Comments Sort Order [18] => Default Notification Mode [19] => Notification Method Wh... ) ) ) )

The important bit is at the end:
[submit] => Submit [modid] => 20 [redirect_url] => admin/permissions.php

These come from some hidden text boxes and show up on the local machine and but not at the hosted site. This causes the failure as '../groupperm.php' isn't given a module to update ([modid] => 20).

Any ideas what can cause this on one server and not another?

Correct. Only one record has uid=1 and groupid=1.

No other record has uid=1 or groupid=1

Good idea!

Just tried it but the problem is still there. Keep the ideas coming, there must be something causing this. Probably something really simple!

Thanks John. I hadn't realized.

I thought it may have been me not using the system correctly.

In addition to the webmaster account, I have a 'site admin' account that has access to the permission changing areas in modules. These are 2 separate accounts and I log out and back in when changing from one to the other.

The webmaster account is only in Webmaster and Registered Users groups. The 'site admin' account is not in the Webmaster group but is in Registered Users and 9 others.

The problem shows up with either account.