I've got some issues with multiple wikis timing out and forcing multiple logins throughout the day. They're all hosted on the same machine in different subdirectories (for various reasons).
I do recall that there is some functionality to tweak how these wikis create their cookies.. in theory they could all share the same one. I'm not sure where to begin looking for the answers so I thought I'd ask.
It's not clear that multiple MediaWiki's _can_ share the same user cookie if you are using the login code as-shipped.
Each wiki has its own user table and its own user tokens. If you log in to one wiki (say, "W1"), it puts a token in your cookie and writes it in its W1 user table. When you go to another wiki ("W2"), it checks your token from the cookie and ... Doesn't find it in _its_ user table. When the token is not found, you are not considered to be logged in. So you have to log in to W2. W2 generates a new token, and writes the token in the cookie. Now suppose you go back to W1. W1 checks your token from the cookie -- but the new W2 token isn't in _its_ (W1) user table. So you have to log in again to W1.
Mashing the code to use the same user table for different wikis is well beyond _my_ appetite for punishment, but you may feel differently.
If you really want single signon, check out Gregory Szorc's comments earlier today (as replayed by Matt England):
At 3/25/2006 11:30 AM, Gregory Szorc wrote:
There are multiple ways to implement single sign-on (SSO). The way you describe, a user goes to a URL, signs in, and gets logged in to other applications right there and then using HTTP calls on behalf of a user. This is pretty insecure and a pain to implement. It also doesn't scale very well.
Another way to implement single sign-on is with a single sign-on server, which has a single sign-on protocol. When a user logs in to any application using SSO, they get whisked away to the SSO server. If they aren't logged in to the server, they get prompted for their credentials. When they are logged in, they get signed in to the desired application.
As for SSO servers, I recommend CAS (http://www.ja-sig.org/products/cas/). It has clients for almost every language, including PHP, and the protocol is simple enough to create clients in other languages. I have successfully deployed MediaWiki behind it. It shouldn't be difficult getting it to work with the other applications either.
Gregory Szorc gregory.szorc@case.edu
-- Joshua
On 3/24/06 2:18 PM, "Sy Ali" sy1234@gmail.com wrote:
I've got some issues with multiple wikis timing out and forcing multiple logins throughout the day. They're all hosted on the same machine in different subdirectories (for various reasons).
I do recall that there is some functionality to tweak how these wikis create their cookies.. in theory they could all share the same one. I'm not sure where to begin looking for the answers so I thought I'd ask. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On 3/27/06, Joshua Yeidel yeidel@wsu.edu wrote:
It's not clear that multiple MediaWiki's _can_ share the same user cookie if you are using the login code as-shipped.
This isn't a big enough issue to warrant my going overboard to solve it.
Ok, so how do I force the different mediawiki installs to use separate cookies, to ensure that they don't clobber oneanother?
It does appear to me that something fishy is going on.. because although I don't clear my cookies and have mw remember my password.. sometimes I have to re-log in.
It's not consistant.. so I'm still confused as to what's going on.
You can use the $wgCookiePath. This variable is set in LocalSettings.php, and in turn sets a property of the cookie. When the cookie path matches (from left-to-right) the URL of a request, the browser sends the cookie along with that request.
For example, if you have two wikis:
And
Then you set the $wgCookiePath to "/wiki1" in wiki1/LocalSettings.php, and to "/wiki2" in wiki2/LocalSettings.php. Then each wiki never sees the other's cookies.
Note: This is good in theory, but untested (though we're working on it). The situation is more complex if you are using mod_rewrite or other short-URL tricks. There may also be an issue with PHPSESSIONID and its cookies. Others on the list may know more...
-- Joshua
On 3/27/06 5:52 PM, "Sy Ali" sy1234@gmail.com wrote:
On 3/27/06, Joshua Yeidel yeidel@wsu.edu wrote:
It's not clear that multiple MediaWiki's _can_ share the same user cookie if you are using the login code as-shipped.
This isn't a big enough issue to warrant my going overboard to solve it.
Ok, so how do I force the different mediawiki installs to use separate cookies, to ensure that they don't clobber oneanother?
It does appear to me that something fishy is going on.. because although I don't clear my cookies and have mw remember my password.. sometimes I have to re-log in.
It's not consistant.. so I'm still confused as to what's going on. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Sy Ali wrote:
On 3/27/06, Joshua Yeidel yeidel@wsu.edu wrote:
It's not clear that multiple MediaWiki's _can_ share the same user cookie if you are using the login code as-shipped.
This isn't a big enough issue to warrant my going overboard to solve it.
Ok, so how do I force the different mediawiki installs to use separate cookies, to ensure that they don't clobber oneanother?
You don't have to, they already do that.
It does appear to me that something fishy is going on.. because although I don't clear my cookies and have mw remember my password.. sometimes I have to re-log in.
Sessions expire.
-- brion vibber (brion @ pobox.com)
Just to be sure this is in perspective: by default each wiki writes a separate cookie that is named with the wiki DB name. The collision I describe below would take place _only_ if, as suggested earlier, wikis were to use the _same_ user cookie.
-- Joshua
On 3/27/06 5:17 PM, "Joshua Yeidel" yeidel@wsu.edu wrote:
It's not clear that multiple MediaWiki's _can_ share the same user cookie if you are using the login code as-shipped.
Each wiki has its own user table and its own user tokens. If you log in to one wiki (say, "W1"), it puts a token in your cookie and writes it in its W1 user table. When you go to another wiki ("W2"), it checks your token from the cookie and ... Doesn't find it in _its_ user table. When the token is not found, you are not considered to be logged in. So you have to log in to W2. W2 generates a new token, and writes the token in the cookie. Now suppose you go back to W1. W1 checks your token from the cookie -- but the new W2 token isn't in _its_ (W1) user table. So you have to log in again to W1.
Mashing the code to use the same user table for different wikis is well beyond _my_ appetite for punishment, but you may feel differently.
If you really want single signon, check out Gregory Szorc's comments earlier today (as replayed by Matt England):
At 3/25/2006 11:30 AM, Gregory Szorc wrote:
There are multiple ways to implement single sign-on (SSO). The way you describe, a user goes to a URL, signs in, and gets logged in to other applications right there and then using HTTP calls on behalf of a user. This is pretty insecure and a pain to implement. It also doesn't scale very well.
Another way to implement single sign-on is with a single sign-on server, which has a single sign-on protocol. When a user logs in to any application using SSO, they get whisked away to the SSO server. If they aren't logged in to the server, they get prompted for their credentials. When they are logged in, they get signed in to the desired application.
As for SSO servers, I recommend CAS (http://www.ja-sig.org/products/cas/). It has clients for almost every language, including PHP, and the protocol is simple enough to create clients in other languages. I have successfully deployed MediaWiki behind it. It shouldn't be difficult getting it to work with the other applications either.
Gregory Szorc gregory.szorc@case.edu
-- Joshua
On 3/24/06 2:18 PM, "Sy Ali" sy1234@gmail.com wrote:
I've got some issues with multiple wikis timing out and forcing multiple logins throughout the day. They're all hosted on the same machine in different subdirectories (for various reasons).
I do recall that there is some functionality to tweak how these wikis create their cookies.. in theory they could all share the same one. I'm not sure where to begin looking for the answers so I thought I'd ask. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On 3/28/06, Joshua Yeidel yeidel@wsu.edu wrote:
Just to be sure this is in perspective: by default each wiki writes a separate cookie that is named with the wiki DB name.
And so here is the cause of the problem. They're all using the same database, but with a different tag on their table entries.
Perhaps the cookies should be automatically named based on both the database name and the tag name.
On 29/03/06, Sy Ali sy1234@gmail.com wrote:
Perhaps the cookies should be automatically named based on both the database name and the tag name.
I have a vision of a page on Meta somewhere which details a workaround for this; it involves changing the session_name line somewhere.
Rob Church
On 3/29/06, Rob Church robchur@gmail.com wrote:
On 29/03/06, Sy Ali sy1234@gmail.com wrote:
Perhaps the cookies should be automatically named based on both the database name and the tag name.
I have a vision of a page on Meta somewhere which details a workaround for this; it involves changing the session_name line somewhere.
Mine is that all configuration options are documented on their own page. I searched on meta and found the one. Then I confirmed that it's information has been migrated to its proper home.
http://meta.wikimedia.org/wiki/Help:Configuration_settings_index#.24wgCookie...
http://www.mediawiki.org/wiki/Help:%24wgCookiePath
I'll document my experiences once I figure out a solution.
On 3/29/06, Sy Ali sy1234@gmail.com wrote:
I'll document my experiences once I figure out a solution.
Ok, I reproduced, resolved and tested this issue. Both the FAQ and topic page have been updated.
On 3/29/06 10:28 AM, "Rob Church" robchur@gmail.com wrote:
On 29/03/06, Sy Ali sy1234@gmail.com wrote:
Perhaps the cookies should be automatically named based on both the database name and the tag name.
I have a vision of a page on Meta somewhere which details a workaround for this; it involves changing the session_name line somewhere.
Perhaps you are thinking of this:
if ( $wgDBprefix ) { session_name( $wgDBname . '_' . $wgDBprefix . '_session' ); } else { session_name( $wgDBname . '_session' ); }
... Which is lines 120ff. of Setup.php in MW 1.5.6.
This seems to make it unnecessary to use $wgCookiePath in the case where wikis are sharing the same database, and their tables are distinguished by $wgDBprefix. The session cookies will also be distinguished by $wgDBprefix.
But the situation may be a little more complex:
In 1.5.6, there are four cookies that are issued by MW: the PHP session cookie, the UserID cookie, the Username cookie, and the Token cookie. The name of the PHP session cookie is qualified by the DBname and the DBprefix (if any); the last three are qualified by the Dbname _only_, regardless of the DBprefix. (See User.php, function setCookies() , lines 1222 ff.) All four have their path and domain set by $wgCookiePath and $wgCookieDomain, respectively.
It appears to me that the main purpose of the three MW-specific cookies is to cope when the PHP cookie does not behave as the wiki owner would like (e.g., in hosting situations, where PHP session may not be supported at all). Therefore, a fix that just involves the PHP session cookie may work in some environments, and break in others.
-- Joshua
Rob Church _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Apparently it was not beyond the MW developers, bless 'em. From the MediaWiki 1.6 Release Notes http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/RELEASE-NOTES?view=m arkup:
- Allow cookies to be shared between multiple wikis with a shared user
database
-- Joshua
On 3/27/06 5:17 PM, "Joshua Yeidel" yeidel@wsu.edu wrote:
Mashing the code to use the same user table for different wikis is well beyond _my_ appetite for punishment, but you may feel differently.
On 3/29/06, Joshua Yeidel yeidel@wsu.edu wrote:
Apparently it was not beyond the MW developers, bless 'em. From the MediaWiki 1.6 Release Notes http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/RELEASE-NOTES?view=m arkup:
Good to hear. I've noted that in http://www.mediawiki.org/wiki/Help:%24wgCookiePath
Adding this leads me wonder why documentation isn't held in a more version-specific manner.
On 30/03/06, Sy Ali sy1234@gmail.com wrote:
Adding this leads me wonder why documentation isn't held in a more version-specific manner.
Because, to be frank about it, our documentation is shit. Want to help improve it?
Rob Church
Rob Church wrote:
On 30/03/06, Sy Ali sy1234@gmail.com wrote:
Adding this leads me wonder why documentation isn't held in a more version-specific manner.
Because, to be frank about it, our documentation is shit. Want to help improve it?
Rob Church
may be once. For now I have 2/3 month work (on fr.opensuse.org) then I could help.
it's not necessarily so difficult, the doc is here, just need some cleaning
jdd
On 3/30/06, Rob Church robchur@gmail.com wrote:
On 30/03/06, Sy Ali sy1234@gmail.com wrote:
Adding this leads me wonder why documentation isn't held in a more version-specific manner.
Because, to be frank about it, our documentation is shit. Want to help improve it?
I've been waiting on a per-namespace announcement feature. I think it's mostly done. It'll be used by the docs guys to announce the closing of docs in certain sections on certain websites and the redirection to the proper home.
Then things will need to be rewritten from scratch so they're public domain, and can thereby be included in a default install or as a downloadable package.. so that a new installation can come with docs.
Right below this:
$wgSitename = "Your Wiki Name";
add the line:
ini_set("session.name", "{$wgSitename}Session");
So that it looks like:
$wgSitename = "Your Wiki Name"; ini_set("session.name", "{$wgSitename}Session");
I host dozens on the same domain like this - works great. Creates a separate session for each wiki, and thus different cookies.
- MHart
----- Original Message ----- From: "Sy Ali" sy1234@gmail.com To: "MediaWiki announcements and site admin list" mediawiki-l@wikimedia.org Sent: Friday, March 24, 2006 5:18 PM Subject: [Mediawiki-l] Multiple wikis - dealing with cookies
I've got some issues with multiple wikis timing out and forcing multiple logins throughout the day. They're all hosted on the same machine in different subdirectories (for various reasons).
I do recall that there is some functionality to tweak how these wikis create their cookies.. in theory they could all share the same one. I'm not sure where to begin looking for the answers so I thought I'd ask. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org