Suhosin session encrypt

[torob]

Hi.

I have a webhost which also provides email, but since the webhosts webmail is very limited i have installed Roundcube as a replacement. And this works very well until my webhost installed Suhosin, and the suhosin.session.encrypt was enabled.

But I found a solution and here is how:

My webhost runs suPHP which make it possible to use my own php.ini file. I copied the standard php.ini provided from my webhost to the Roundcube directory and added suhosin.session.encrypt=Off to this file.

I also have to add the following to the .htaccess file (in the Roundcube directory) to make it use the custom php.ini file:

<IfModule mod_suphp.c>
  suPHP_ConfigPath <path to roundcube directory>
</IfModule>

This works very well and only disables session encryption for the Roundcube directory. I have as an additional security forced Roundcube to only use https connections.


But when upgrading to a new version of Roundcube a problem occurs. Since my webhost enabled Suhosin after I installed it i didn't have any problem when installing it the first time.

I used the installto.sh script as described in the upgrading document, but this failed since the session encrypt is enabled in the temporary install directory. I tried to disable it, but I guess custom php.ini file doesn't work when running from command line.

The way I solved this was to change suhosin.session.encrypt to 1 in program/include/iniset.php in the temporary install directory and then run the install script. This works fine, but afterwards I need to add the extra lines to the .htaccess file again as the upgrade script overwrite it. I also changed the suhosin.session.encrypt back to 0 in program/include/iniset.php in the Roundcube directory.

And then everything seems to work very fine.

I'm not an expert, but I like to share my experience and hope this can help other users having problem with Roundcube and Suhosin.

But I have a question about changing the iniset.php file during the upgrade. Is there any disadvantages by doing it this way?

[SKaero]

I don't think there any disadvantages to doing it that way, something you many to try (haven't tried it myself) is putting the php.ini file in the installer directory as the php.ini files only affect the scripts run from the directory the php.ini file is in. I know that works for web access but I haven't tried it for command line access.

[torob]

Thank you for your reply.

I tried to put the php.ini in the install directory, but it doesn't seem to work. As far as I know, it works a little different when running php script from the command line, so I guess that's the reason it wouldn't work.

But anyway, the other method seems to work well so I will use that on upgrades in the future.

[bpat1434]

When running PHP from the CLI it by default will use a different php.ini that the webserver php.ini.  This is because you can harness more power via the CLI than you normally can in apache AND it should be running in a more secure fashion (e.g. you know who's executing it).

You can tell it to use a specific php.ini file if you want:

Code: [Select]

php --php-ini <path_to_ini_file> script.php