Last modified: 2010-05-15 15:59:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13082 - Though user is logged in, switching pages seems to force a logout
Though user is logged in, switching pages seems to force a logout
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
Other Linux
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-02-20 04:03 UTC by Chris Wisniewski
Modified: 2010-05-15 15:59 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Screen shots: Successfully logged in, Not logged in, Cannot edit common.css (445.44 KB, image/png)
2008-02-20 04:03 UTC, Chris Wisniewski

Description Chris Wisniewski 2008-02-20 04:03:20 UTC
Created attachment 4660 [details]
Screen shots: Successfully logged in, Not logged in, Cannot edit common.css

Though I have logged in successfully with a given user, a switch to a different page/article reveals that I am no longer logged in. 

Thinking this might be related to the one and only user that was set-up in my Wiki, I created a new user (successfully), activated it's e-mail feature via the automated e-mail that arrived to its associted e-mail account (successfully), and then tried to view that user's preferences page, which returned 'Not Logged In'. Indeed, the header suggests that the user is not logged in. 

This same problem is present when the main admin account (for my site, "Histwikiadmin") is active. There I was trying to edit MediaWiki:Common.css but was never able to presumably because I was not logged in. E.g.--I logged into to Histwikiadmin (successfully), redirected to MediaWiki:Common.css (, but am told that "This locked to prevent abuse." Indeed, the header suggests that the user is not logged in and there is only a "view source" tab on the page, no "edit" tab.

See the attached screen shots.

p.s. I am an iPowerWeb customer. iPowerWeb's system specs for my account are:

Platform Type: Debian
MySQL Version: 5.0.45
Perl Version: 5.8.8
PHP Version: 5.2.2

The form for bug submission does not include 'Debian' but it is a GNU/Linux app.
Comment 1 OverlordQ 2008-02-20 04:08:21 UTC
I'm guessing config issue, cookies aren't being sent properly:

Set-Cookie: wiki_wiki_UserID=3; expires=Fri, 21-Mar-2008 04:07:49 GMT; path=/
Set-Cookie: wiki_wiki_UserName=DigitalPants; expires=Fri, 21-Mar-2008 04:07:49 GMT; path=/
Set-Cookie: wiki_wiki_Token=deleted; expires=Tue, 20-Feb-2007 04:07:48 GMT
Comment 2 Chris Wisniewski 2008-02-21 05:15:42 UTC
(In reply to comment #1)

> I'm guessing config issue, cookies aren't being sent properly...


Using Firefox, I logged out if the wiki, cleared all cookies, and then logged into the Wiki. 3 cookies were set: 

Name: wiki_wiki_UserName
Content: Cwisniewski
Path: /
Send For: Any type of connection
Expires: Fri, Mar 21, 2008 10:43:21 PM [e.g. 48 hours]

Name: Name: wiki_wiki_UserID
Content: 2
Path: /
Send For: Any type of connection
Expires: Fri, Mar 21, 2008 10:43:21 PM [e.g. 48 hours]

Name: Name: wiki_wiki__session
Content: 662e1991013f70bc1494e5f790fe20b3
Path: /
Send For: Any type of connection
Expires: at end of session

After the login, I closed Firefoxe's cookie view window, and tried to view my preferences (e.g., the "my preferences" link at the top of the screen). The inteface, like before, as can be seen in screen shot 2, indicates that I am not logged in. I re-opened Firefox's cookie view window. All 3 cookies are still intact and are identical in all respects to their states as before. No other cookies have been added. 

Is this not the correct cookie behavior?  Note that I do not have a "wiki_wiki_Token", as is the case with Brent's snippet above.
Comment 3 OverlordQ 2008-02-21 05:22:30 UTC
Meh, I rescind my previous judgment, I get the same set-cookie headers on my test wiki that works:

Set-Cookie: wikidbUserID=1; expires=Sat, 22-Mar-2008 05:16:44 GMT; path=/
Set-Cookie: wikidbUserName=OverlordQ; expires=Sat, 22-Mar-2008 05:16:44 GMT; path=/
Set-Cookie: wikidbToken=deleted; expires=Wed, 21-Feb-2007 05:16:43 GMT

Still guessing some sort of misconfiguration though. Don't quote me on that.
Comment 4 Chris Wisniewski 2008-02-23 16:04:22 UTC
Based on a comment from another bug in the system about a similar problem appearing in post 1.9.3 versions of MediaWiki, I killed my installation, including databases and installed 1.9.3 in its place. 

Same problem occurs. 

Any advice in the meantime? If I can't stay log in as anyone the system is almost totally useless to me. 
Comment 5 Brion Vibber 2008-02-26 22:43:20 UTC
This sounds like a classic "PHP session data isn't being preserved because I'm on a web farm where the PHP session file directory isn't set up on a shared partition" situation. You should find some notes on this in some of the installation guides on
Comment 6 Chris Wisniewski 2008-02-27 00:15:55 UTC
Thanks, Brion, for your suggestion. Would you (or anyone else) mind providing a more concrete reference within an installation guide? I did some searching on keywords -- even the text that was quoted -- but didn't come up with anything. 
Comment 7 Brion Vibber 2008-02-27 00:54:13 UTC
The one that always comes to mind is the guide to installing on SourceForge's shared servers:

Check if your host has a recommended spot for persistent temporary files, or you can create one in your home area usually.
Comment 8 Chris Wisniewski 2008-02-28 03:15:08 UTC

Thanks very much for your help. With the pointer that you provided me I was able to solve my problem. 

It would be good if the Wiki install script could somehow be directed to knowing that a "shared server" or "server farm" (or whatever wants to call it) type of install is being executed and make the appropriate change to LocalSettings.php. That is, to add:

   ini_set('session.save_path','<account_path_data>/<php_session_data folder>/');

between the lines located near the top of the file that read:

   set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR . get_include_path() );
   require_once( "includes/DefaultSettings.php" );

For those potential users hosting their wiki at iPowerWeb, bypass if at all possible PowerWeb's pitiful chat support (I waited 1:15 on the line before a first level agent -- who had heard of PHP but could not understand my question or really anything beyond telling me the day of the week or the weather conditions where they were at -- answered my call). It was only after the call and after using google (not only are PowerWeb's chat agents uninformed, but the search function for their FAQ and knowledgebase is not very useful either--unless, that is, one knows exactly what they are looking for and by chance uses one of iPowerWeb's seemingly very limited keywords for a given topic) that I discovered that iPowerWeb itself offered similar advice. Alas, if only one knew where to look for it!

For further help see:

     (only available after logging into one's "vdeck "3.0" account) 
From the second URL one can see the location of their "web document root": for example, "/home/users/web/<some_folder>/ipw.<account_name>/public_html" 

Replace the last subdirectory of whatever path was given (e.g.--"/public_html") with "/phpsessions". It turns out that the "phpsessions" directory is automatically provided by default in one's folder tree within the 3.0 system (at least in my case it was).    
Comment 9 Brion Vibber 2008-02-28 21:11:10 UTC
Testing the session support to this degree would likely be possible with a little JavaScript action, autosubmitting a couple of forms and testing that they all go through to the backend. Probably feasible...

Alternately / in addition, we could "just" include a database backend for sessions by default.

Note You need to log in before you can comment on or make changes to this bug.