Last modified: 2010-05-15 15:59:51 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 (http://www.cwisniewski.com/wiki/index.php5?title=MediaWiki:Common.css&action=edit), but am told that "This page...is 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.
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 ====
(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 Host: www.cwisniewski.com 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 Host: www.cwisniewski.com 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 Host: www.cwisniewski.com 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.
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.
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.
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 mediawiki.org.
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.
The one that always comes to mind is the guide to installing on SourceForge's shared servers: http://www.mediawiki.org/wiki/SourceForge#Sessions Check if your host has a recommended spot for persistent temporary files, or you can create one in your home area usually.
Brion, 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: http://www.spungesoft.com/having-trouble-with-php_sessions/ and http://members.ipower.com/member/cgiManagement/PHPplus.bml (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).
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.
