-
2007-03-20
wongyb
For server that runs PHP scripts using suPHP under Apache, all files created by that PHP script will be owned by the script file owner (but not the owner running Apache). The use of suPHP is for security reason. It is to prevent users of the same server to read sensitive files of another user.
Session file created in /tmp, /var/run, or /var/lib/php5 depending on the server setting will also be owned by the script owner. Dokuwiki set session in inc/init.php. The session name is "Dokuwiki". Problem occurs in when accessing wikis owned by two different users using the same web browser. Since the session name is "Dokuwiki" for these two Dokuwiki installations, the same cookie is going to be retrieved, and hence the same session file stored in the server. Upon accessing the second user wiki, session_start() complains "Permission denied".
To cater for this problem, I tried to patch inc/init.php as illustrated below. This modification relies on setting $conf['basedir'] in conf/local.php.
I hope this (or any fix to cater for this problem) could be included in the future Dokuwiki release.
--- /public/wongyb/dokuwiki-2006-11-06/inc/init.php 2006-11-07 03:32:07.000000000 +0800
+++ inc/init.php 2007-03-15 13:34:36.013737000 +0800
@@ -85,7 +85,9 @@
// init session
if (!headers_sent() && !defined('NOSESSION')){
- session_name("DokuWiki");
+ $cookie_path = (isset($conf['basedir'])&&!empty($conf['basedir'])) ? $conf['basedir'] ."/" : dirname($_SERVER[PHP_SELF])."/";
+ session_name("DokuWiki".$cookie_path);
+ session_set_cookie_params( 0, $cookie_path );
session_start();
}
-
2007-03-26
andi
Shouldn't setting the cookie scope to DOKU_BASE with session_set_cookie_params be enough? Or am I missing something? Why do you change the session name as well?
-
2007-03-27
wongyb
DOKU_BASE works as well and it is simpler to use. However, session_regenerate_id() needs to be called before session_start(), otherwise the same error message appears
diff -ur dokuwiki-2006-11-06/inc/init.php dokuwiki-patched/inc/init.php
--- dokuwiki-2006-11-06/inc/init.php 2007-03-27 13:02:45.499934000 +0800
+++ dokuwiki-patched/inc/init.php 2007-03-27 13:02:13.240074000 +0800
@@ -86,6 +86,8 @@
// init session
if (!headers_sent() && !defined('NOSESSION')){
session_name("DokuWiki");
+ session_set_cookie_params( 0, DOKU_BASE );
+ session_regenerate_id();
session_start();
}
-
2007-03-31
andi
Hmm if I understand the docs correctly this would create a new session ID for each page call. I'm not understand how this is helpful in your case.
-
2007-04-10
wongyb
A simple get around for me is to set a different session name for my top-most wiki.
Many wikis are hosted in my server. The DOKU_BASE of the users wikis are /wikis/<username>. The DOKU_BASE of the system wiki is '/'.
When web surfers visited the system wiki first, setting a cookie in their web browser with session name "DokuWiki" and path "/", the problem would occur when they subsequently access the users' wiki which would also request for session info from cookie with path '/'.
A simple get around is to set the system wiki to a different session name, like 'Dokuwiki-systemwide', while leave all users wiki session name unchanged. Since all users' wikis are of the same level as far as the cookie path is concerned.
-
2007-06-23
andi
Is this problem still an issue with the latest RC release?
-
2007-06-26
wongyb
I think so.
The only option for me seems to be to append DOKU_BASE (or whatever unique within the webspace) to the session name "DokuWiki" in inc/init.php line 92.
I think this might not be a problem for the majority of the people who are not using 'suphp'. Using suphp, the session variable "sess_*" in /var/lib/php5 is owned by the owner of the PHP script and could not be modified when accessing another wiki owned by another user in the same server.
-
2007-09-16
ChrisS
This seems a fairly easy thing to overcome without significant side-effects. Why not set the session name to the wiki title - or some cleaned up version that avoids special chars (e.g. DW_splitbrain) and/or let the session name be changed in the site configuration?
-
2007-09-18
wongyb
Yes are right. That's what I am doing now. However, it requires modification of the software which is not supposed to do. All changes should be restricted to configuration file as far as we can. For me, I could modify the program myself, but not many people could (or like to) do. If modifying the session name is the only solution, I would suggest we make it at the config file. ;)
-
2008-10-11
andi
Okay, I think I got it now. The problem occurs when multiple wiki installations are nested within each other. Like in your case one master in / and many user one in /wiki/*. I'd say this is a edge case and would recommend to use subdomains instead.
I'm a bit reluctant on chnaging the session name as it is well established and changing it to a more dynamic one could create SEO problems...
-
Related tasks: