Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1493 closed defect (invalid)

session expires after upgrading to Trac 0.10.4

Reported by: dominiksh@… Owned by: mgood
Priority: highest Component: AccountManagerPlugin
Severity: blocker Keywords:
Cc: Trac Release: 0.10

Description

I successfully used the AccountManagerPlugin with version 0.10.3.1 of Trac + MySQL. After the release of Trac 0.10.4 I updated my Trac installation to fix some issues related to MySQL.

After upgrading to 0.10.4, AccountManagerPlugin does not seem to work correctly anymore: Whenever I visit one of my Trac projects and login, my session expires after a short time, sometimes directly after login. The logfile did not prevennt any useful messages, although I set the log level to DEBUG.

This issue forced me to downgrade to 0.10.3.1 again (I had made a Backup of course).

Attachments (1)

mysql-autologoutbug.patch (576 bytes) - added by amax@… 7 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by anonymous

  • Priority changed from normal to high

comment:2 Changed 7 years ago by zzj1213@…

  • Priority changed from high to highest
  • Severity changed from critical to blocker

same problem for 0.11.6

could not login at all.

comment:3 Changed 7 years ago by anonymous

works fine from http://localhost, but not from remote login http://ipaddress

comment:4 follow-up: Changed 7 years ago by zzj1213@…

change the to check_auth_ip = false.

for users with NAT connection, the req.remote_addr changes which make auth fails, thus this check_auth_ip must be disabled

comment:5 in reply to: ↑ 4 Changed 7 years ago by mgood

  • Resolution set to invalid
  • Status changed from new to closed

Replying to zzj1213@yahoo.com:

change the to check_auth_ip = false.

for users with NAT connection, the req.remote_addr changes which make auth fails, thus this check_auth_ip must be disabled

That's a built-in Trac setting, so this is not an issue related to the plugin.

comment:6 Changed 7 years ago by dominiksh@…

  • Resolution invalid deleted
  • Status changed from closed to reopened

During the last two weeks I did not have time to try the suggested solution. But now I did: I changed check_auth_ip to false, but that did not solve the problem: The session still expires.

Something must have changed from 0.10.3 to 0.10.4 that makes AccountManagerPlugin fail.
So I reopened the ticket and will now wait for some hints...

comment:7 in reply to: ↑ description Changed 7 years ago by amax@…

Replying to dominiksh@web.de:

After upgrading to 0.10.4, AccountManagerPlugin does not seem to work correctly anymore: Whenever I visit one of my Trac projects and login, my session expires after a short time, sometimes directly after login. The logfile did not prevennt any useful messages, although I set the log level to DEBUG.

We are experiencing this issue as well. I've traced the problem to a specific sql query:

http://trac.edgewall.org/browser/tags/trac-0.10.4/trac/web/auth.py#L181

When the user successfully logs in, a trac_auth cookie is set, and its value stored in a row in the mysql auth_cookie table. The query linked to above is meant to detect whether the trac_auth's value has been set on subsequent requests. (Line 181's query is called if trac.check_auth_ip is off; if on, the query a few lines before is called instead. Everything in this post applies to both cases.)

This query is made on each page request. In our testing, the query successfully detects that row in the first handful of requests after login, like it should. Then it fails (i.e. cursor.fetchone() returns None). That is why you can log in, and then click around a bit before it logs you out. We haven't figured out why the query on the last request fails: we verified that the row it's selecting for is indeed in the table before and after (via the command-line mysql client, on a different connection) - it really seems like it should find it.

We are using Trac 10.4, with Python2.4 and MySQLdb 1.22, with MySQL 5.0.37 on RH ES 4 (i686). We are also using TracAccountManager 0.1.3dev and TracWebAdmin 0.1.2dev, though like I said, the problem seems to be in encapsulated in the core trac auth module (or mysqldb or mysql).

We are using Apache 2.0.52, with a recent checkout of mod_wsgi (http://code.google.com/p/modwsgi/). We experienced this auto-logout behavior with mod_python as well, though I did not drill down at to same level of detail. (The user's experience in the browser seems identical using both mod_wsgi and mod_python.)

We are still figuring out why the query fails that last time. Any assistance from persons more knowledgeable on trac internals is appreciated. Thanks in advance.

Peace,

Aaron Maxwell

SnapLogic - Open Source Internet Data Services

http://snaplogic.org

Changed 7 years ago by amax@…

comment:8 follow-ups: Changed 7 years ago by amax@…

A possible fix:

attachment:mysql-autologoutbug.patch

Aaron Maxwell

SnapLogic - Open Source Internet Data Services

http://snaplogic.org

comment:9 in reply to: ↑ 8 Changed 7 years ago by anonymous

As a followup/extra data point, we have been using the above patch for about two weeks now on our production trac, and so far have had no issues.

Aaron Maxwell

SnapLogic - Open Source Internet Data Services

http://snaplogic.org

comment:10 in reply to: ↑ 8 Changed 7 years ago by mgood

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to amax@snaplogic.org:

A possible fix:

attachment:mysql-autologoutbug.patch

Based on that this appears to be an issue in Trac itself and not this plugin, so can you open a ticket on the main Trac site for this?

Also, can you keep the footers to a minimum? We can tell from your email that you work for SnapLogic.

comment:11 Changed 7 years ago by amax@…

comment:12 Changed 7 years ago by cboos

(patch now applied for Trac 0.10.5dev and 0.11dev)

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.