Specify operating systems

[squirrelmail.git] / include / init.php

diff --git a/include/init.php b/include/init.php
index d0709d1603ce137480186b81a9800389a24fb4a3..d677942d77d4e95127f5e8cee9d2f04b6c94fd01 100644 (file)
--- a/include/init.php
+++ b/include/init.php
@@ -251,6 +251,51 @@ if (PAGE_NAME == 'login') {
     if (!empty($_SESSION))
         $_SESSION = array();
 
+    /**
+     * Allow administrators to define custom session handlers
+     * for SquirrelMail without needing to change anything in
+     * php.ini (application-level).
+     *
+     * In config_local.php, admin needs to put:
+     *
+     *     $custom_session_handlers = array(
+     *         'my_open_handler',
+     *         'my_close_handler',
+     *         'my_read_handler',
+     *         'my_write_handler',
+     *         'my_destroy_handler',
+     *         'my_gc_handler',
+     *     );
+     *     session_module_name('user');
+     *     session_set_save_handler(
+     *         $custom_session_handlers[0],
+     *         $custom_session_handlers[1],
+     *         $custom_session_handlers[2],
+     *         $custom_session_handlers[3],
+     *         $custom_session_handlers[4],
+     *         $custom_session_handlers[5]
+     *     );
+     *
+     * We need to replicate that code once here because PHP has
+     * long had a bug that resets the session handler mechanism
+     * when the session data is also destroyed.  Because of this
+     * bug, even administrators who define custom session handlers
+     * via a PHP pre-load defined in php.ini (auto_prepend_file)
+     * will still need to define the $custom_session_handlers array
+     * in config_local.php.
+     */
+    global $custom_session_handlers;
+    if (!empty($custom_session_handlers)) {
+        $open    = $custom_session_handlers[0];
+        $close   = $custom_session_handlers[1];
+        $read    = $custom_session_handlers[2];
+        $write   = $custom_session_handlers[3];
+        $destroy = $custom_session_handlers[4];
+        $gc      = $custom_session_handlers[5];
+        session_module_name('user');
+        session_set_save_handler($open, $close, $read, $write, $destroy, $gc);
+    }
+
     sqsession_is_active();
     session_regenerate_id();
 
@@ -273,6 +318,7 @@ $SQM_INTERNAL_VERSION[2] = intval($SQM_INTERNAL_VERSION[2]);
 /* load prefs system; even when user not logged in, should be OK to do this here */
 require(SM_PATH . 'functions/prefs.php');
 
+// FIXME: config/plugin_hooks.php has not yet been loaded (see a few lines below); so this hook call should I think not be working -- has anyone actually tested it?  Is there any reason we cannot move this prefs code block down below "MAIN PLUGIN LOADING CODE HERE" (see below)?  Reading the code, I *think* it should be OK, but....   Also, note that this code would then be placed immediately next to the config_override hook, and since it makes little sense to execute two hooks in a row, I will propose removing config_override (although sadly, it is less clear to plugin authors that they should use the prefs_backend hook to do any configuration override work in their plugin)
 $prefs_backend = do_hook('prefs_backend', $null);
 if (isset($prefs_backend) && !empty($prefs_backend) && file_exists(SM_PATH . $prefs_backend)) {
     require(SM_PATH . $prefs_backend);