Page MenuHomePhabricator

Losing Login Session Randomly
Closed, DeclinedPublic

Description

Author: timwi

Description:
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?


Version: unspecified
Severity: normal

Details

Reference
bz290

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:52 PM
bzimport set Reference to bz290.
bzimport added a subscriber: Unknown Object (MLST).

timwi wrote:

*** Bug 309 has been marked as a duplicate of this bug. ***

Old issue and/or specific to sourceforge.net.
I remember we had a trouble like that but it is no more
happening nowaday.

harald wrote:

(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.

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

harald wrote:

(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.

epriestley changed the task status from Declined to Resolved by committing Unknown Object (Diffusion Commit).Mar 4 2015, 8:19 AM
epriestley added a commit: Unknown Object (Diffusion Commit).
Aklapper changed the task status from Resolved to Declined.Mar 4 2015, 11:29 AM
Aklapper claimed this task.