session expires after upgrading to Trac 0.10.4

same problem for 0.11.6

could not login at all.

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

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

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.

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

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

A possible fix:

attachment:mysql-autologoutbug.patch

Aaron Maxwell
SnapLogic - Open Source Internet Data Services
http://snaplogic.org

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

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

Yes and yes:

http://trac.edgewall.org/ticket/5783

Thanks.

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