Last modified: 2011-03-13 18:05:49 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 290 - Losing Login Session Randomly
Losing Login Session Randomly
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 309 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-03 03:08 UTC by Timwi
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

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


Attachments

Description Timwi 2004-09-03 03:08:00 UTC
BUG MIGRATED FROM SOURCEFORGE
http://sourceforge.net/tracker/index.php?func=detail&aid=957258&group_id=34373&atid=411192
Originally submitted by Donny Viszneki - <a href="/users/smirk-/">smirk-</a>  2004-05-20 09:30


Note: Before reading on, you should know this problem also occurs 
on wikipedia.sf.net, I described it below as well.

I have not been able to pinpoint a direct cause yet, however, using 
Safari and MSIE 5.2 under Mac OS X Panther, I randomly lose my 
login session under an installation of MediaWiki that I have just 
installed here at SourceForge. I trust that being on 
SourceForge is enough for you to know concerning my PHP 
configuration and such, since you certainly have access to it to the 
same configuration. Here is a URL to the MediaWiki where I am 
experiencing these problems:

http://cmugcs.sourceforge.net/wiki/

Please help me to address this problem quickly.

Before submitting this report I registered at wikipedia.sf.net and 
had the same problem. Immediately after registering, I could see 
that I was logged in. I clicked preferences, and then I was logged 
out. Whether or not I checked "Remember my password across 
sessions" does not seem to influence this bug.

------------------------- Additional comments ------------------------
Date: 2004-05-20 09:34
Sender: smirk-

I thought it might be a client caching problem. But it occurs
even when
I'm going to pages I've never visited, and even after refreshing
the page.
-------------------------------------------------
Date: 2004-05-20 09:41
Sender: smirk-

This bug is confirmed to occur in Windows MSIE 6.0, Mac OS X
Panther
Safari 1.2.1, Mac OS X Panther MSIE 5.4, and Mac OS X Jaguar
Camino.

Another thing that happens sometimes, is the area where it says
your
username or "Not logged in," sometimes it gives your IP address
and has
a "Log in" link below as though you were not logged in.
-------------------------------------------------
Date: 2004-05-20 09:42
Sender: smirk-

I'm sorry it is not confirmed for Jaguar Camino, it is confirmed
for
Jaguar Chimera 0.6. I apologize for the inconvenience.
-------------------------------------------------
Date: 2004-05-20 22:49
Sender: SF user uninvited1

You may want to check any browser, firewall, or proxy
settings that affect cookie duration.  Many of these limit
cookie duration, which will cause logins to expire.
-------------------------------------------------
Date: 2004-05-20 23:17
Sender: SF user vibber

It seems to be a session handling problem of some sort. Either
PHP's
session system is just broken on Sourceforge, or there's a 4.1.2
incompatibility with the way we use it.

Clicking "save my password across sessions" (which stores a separate
cookie and thus doesn't rely on PHP maintaining the session from
one hit
to the next) always works for me on wikipedia.sourceforge.net,
and also
works for me on cmugcs.sourceforge.net/wiki/.

-------------------------------------------------
Date: 2004-05-20 23:24
Sender: SF user gabrielwicke

If the default session timeout is too short you could just
bump it up a tad. Default is $wgCookieExpiration = 2592000;.
-------------------------------------------------
Date: 2004-05-25 18:05
Sender: SF user teunspaans

I can confirm this on the af:wiki with WXP, IE6, but alas no 
recipe for reproducing it.

-------------------------------------------------
Date: 2004-05-26 01:27
Sender: smirk-

gabirelwicke: I thought I posted a response to this but I guess
I didn't.
Your solution didn't work initially, but the next day the change
seemed to
take effect. I don't know why that is.

Also, isn't 2592000 the equivalent of 43 minutes? That doesn't
seem
right, and I doubt I'm interpretting it in the wrong precision,
because
anything longer than a milllisecond would mean that 2592000 
represented a longer period of time than 43 minutes (a lot more
time.)
-------------------------------------------------
Date: 2004-05-26 01:40
Sender: SF user vibber

The cookie timeout isn't 43 minutes, it's *30 days*. That's not
relevant,
however, as the problem is with PHP's session management specifically
on SourceForge's servers. The cookies with the 30-day timeout
are used
to fill in the last-used username when you next login, and optionally
to
do the login transparently to refresh the session if you also
store the
password. And those cookies work just fine on both of the SF-hosted
wikis mentioned.

The session is stored in a file (usually) on the web server,
and indexed
by a session cookie (which is set to expire at the end of the
browser
session, however long that might be). The session data might
separately
expire, or be deleted, or reside on different back-end servers
which don't
communicate well, or other problems.

-------------------------------------------------
Date: 2004-05-26 01:43
Sender: smirk-

How does this explain that problem having disappeared now that
I've
changed it to ~300 days? Has SourceForge changed their PHP 
installation?
-------------------------------------------------
Date: 2004-05-26 01:50
Sender: SF user vibber

> How does this explain that problem having disappeared now that
> I've changed it to ~300 days?

It hasn't disappeared: I still can't get a login to stick there
without
checking "Remember my password across sessions." (And even then
I'm
having some problems on your wiki with the login spontaneously 
breaking and returning.)
-------------------------------------------------
Date: 2004-05-26 01:59
Sender: smirk-

I am dead serious, I have been editting a LOT (you can check
the recent
changes) and I haven't gotten logged out once since a day after
I made
that change. I'm even editting right now.

Weird huh?
Comment 1 Timwi 2004-09-03 19:41:23 UTC
*** Bug 309 has been marked as a duplicate of this bug. ***
Comment 2 Antoine "hashar" Musso (WMF) 2005-01-27 00:55:32 UTC
Old issue and/or specific to sourceforge.net.
I remember we had a trouble like that but it is no more
happening nowaday.
Comment 3 Harald Albrecht 2005-03-09 16:19:52 UTC
(In reply to comment #2)
> Old issue and/or specific to sourceforge.net.
> I remember we had a trouble like that but it is no more
> happening nowaday.

Sorry to contradict you: I'm right now facing the same problems. I've installed
a mediawiki 1.4rc1 for a SF project and I am facing the same problems.

Browsers: Mozilla 1.7, Mozilla nightly trunk around 2005/03/01, Firefox 1.0+
trunk around 2005/03/01 on W2K. In all cases I usually immediately loose the
login session albeit the cookies are properly set and expiry dates are okay.
Comment 4 Brion Vibber 2005-03-09 21:37:41 UTC
To the last commenter: SourceForge is misconfigured and stores session data 
on the local hard drives in its project web server cluster, where it will not be 
retrieved on subsequent hits served by a different server. Set the 
session.save_path to a networked directory under your project's space (but 
outside your htdocs!)

See http://www.php.net/session and http://www.php.net/ini_set
Comment 5 Harald Albrecht 2005-03-11 08:54:53 UTC
(In reply to comment #4)
> Set the 
> session.save_path to a networked directory under your project's space (but 
> outside your htdocs!)
> 
> See http://www.php.net/session and http://www.php.net/ini_set

Thank you very much for this information. I changed the setting and session
management now works properly.

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


Navigation
Links