Edgewall Software
Modify ↓

Opened 17 years ago

Closed 14 years ago

Last modified 12 years ago

#6121 closed defect (cantfix)

Login/logout with mod_python doesn't work well - probably session problem

Reported by: trebor74hr@… Owned by: Christopher Lenz
Priority: lowest Milestone:
Component: web frontend/mod_python Version: devel
Severity: minor Keywords: session authentication mod_python
Cc: mladen@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Sometimes trac login/logout doesn't work well.

  • sometimes login doesn't logs you in
  • after logged , several clicks, and then you've been logout (no question) you can login again by clicking login - no ask for pwd something with the session on the server.
  • with standalone server (tracd) no problem, only in mod_python installation
  • maybe it is in ie is more often than in ff.

We use Trac 0.11dev-r6038 which is installed on linux(ubuntu7.04)+apache+mod_python.

Apache error.log shows from time to time (sometimes each 40s new entry):

[notice] mod_python: (Re)importing module 'trac.web.modpython_frontend'

maybe this cause these problems.

Trac immediatly forgets my ID and that I am logged in.

I added pythondebug on to apache2.conf, but there was not more output.

In trac.ini I increased log-level to debug. The output is quite big (/opt/trac-intes/log/trac.log), but it isn't producing errors, just strange session manipulation, i.e. seems to be obvious - Session ID changes: 

2007-10-01 15:25:41,674 Trac[session] DEBUG: Retrieving session for ID '42caeaaa0877093b7c89fb86'
2007-10-01 15:25:45,462 Trac[session] DEBUG: Retrieving session for ID 'ulm2'
2007-10-01 15:26:54,386 Trac[session] DEBUG: Retrieving session for ID '27ba53f2a66bc30588f9d545'

Than it works again: 
2007-10-01 15:32:01,210 Trac[session] DEBUG: Retrieving session for ID 'ulm2'
2007-10-01 15:32:01,353 Trac[session] DEBUG: Retrieving session for ID u'ulm2'

And than it doesn't work again:
2007-10-01 15:33:12,157 Trac[session] DEBUG: Retrieving session for ID '189a645348270b5879e40923'
2007-10-01 15:34:00,842 Trac[session] DEBUG: Retrieving session for ID '189a645348270b5879e40923'

And than I try to login again:
2007-10-01 15:35:00,628 Trac[session] DEBUG: Retrieving session for ID '189a645348270b5879e40923'
2007-10-01 15:35:12,231 Trac[main] DEBUG: Dispatching <Request "GET u'/login'">
2007-10-01 15:35:12,330 Trac[session] DEBUG: Retrieving session for ID 'ulm2'
2007-10-01 15:35:13,536 Trac[session] DEBUG: Retrieving session for ID '02aab0875c567d7b77d5debb'

With standalone server (tracd) no problem, i.e. I ran tracd and in the log the Session ID didn't change.

Attachments (4)

login_session_prb1.png​ (13.6 KB ) - added by trebor74hr@… 17 years ago.
is this ok? every login produces new trac_auth, every logout new trac_session, old are not deleted
ticket_6121_workaround.diff​ (1.1 KB ) - added by trebor74hr@… 17 years ago.
workaround
ticket_6121_workaround2.diff​ (412 bytes ) - added by trebor74hr@… 17 years ago.
workaround - try 2
ticket_6121_workaround2.2.diff​ (412 bytes ) - added by trebor74hr@… 17 years ago.
workaround - try 2

Download all attachments as: .zip

Change History (29)

comment:1 by Christian Boos, 17 years ago

Milestone: 0.11

There's maybe something in Apache which messes up the cookies, e.g. ​http://issues.apache.org/bugzilla/show_bug.cgi?id=26002 or something similar.

comment:2 by anonymous, 17 years ago

maybe that could be problem, i'll give a shot. but how do you explain that this problem started to occur after upgrade trac 0.10 to 0.11dev-r6038? Maybe something is still problematic in trac?

in reply to:  1 comment:3 by anonymous, 17 years ago

Replying to cboos:

There's maybe something in Apache which messes up the cookies, e.g. ​http://issues.apache.org/bugzilla/show_bug.cgi?id=26002 or something similar.

sorry didn't use reply button for my last comment.

comment:4 by trebor74hr@…, 17 years ago

It seems that in our case this is happening in trac standalone too, but rare. the same effect. Maybe it has some relation to our db system which is mysql /innodb, maybe something with uncommited changes to db.

What I did: I opened existing ticket 5142, updated it and submit the changes. The changes were saved, but trac logged me out. It is funny that there is request for ticket 5143 which can't be generated in our system since our mysql ticket numbers ending with number 2.

The log is: 

2007-10-03 14:58:26,467 Trac[__init__] DEBUG: Dispatching <Request "POST u'/ticket/5142'">
2007-10-03 14:58:26,562 Trac[__init__] INFO: repos rev [1506] != cached rev [1504]
2007-10-03 14:58:26,826 Trac[__init__] DEBUG: Caching node change in [1506]: (u'trunk/somefile', 'file', 'edit', u'somefile', 1146)
...
2007-10-03 14:58:27,015 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 14:58:27,030 Trac[__init__] DEBUG: Caching node change in [1506]: (u'trunk/somefile2', 'file', 'edit', u'cvs2svn/somefile2', 13)
...
2007-10-03 14:58:27,483 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:58:27,530 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5142'">
2007-10-03 14:58:27,576 Trac[__init__] DEBUG: Retrieving session for ID 'fc8575b98d84b2acc60eba47'
2007-10-03 14:58:27,576 Trac[__init__] DEBUG: Checking MUPPETS <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 14:58:27,592 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 14:58:27,592 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context '[root]'>
2007-10-03 14:58:27,640 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 14:58:27,640 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_MODIFY on <Context '[root]'>
2007-10-03 14:58:27,655 Trac[__init__] DEBUG: render_ticket_action_control: action "leave"
2007-10-03 14:58:27,655 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:58:27,671 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context '[root]'>
2007-10-03 14:58:27,687 Trac[__init__] DEBUG: No policy allowed anonymous performing BROWSER_VIEW on <Context '[root]'>
2007-10-03 14:58:27,687 Trac[__init__] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Context '[root]'>
2007-10-03 14:58:27,701 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on <Context '[root]'>
2007-10-03 14:58:27,701 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on <Context '[root]'>
2007-10-03 14:58:27,717 Trac[__init__] DEBUG: No policy allowed anonymous performing TIMELINE_VIEW on <Context '[root]'>
2007-10-03 14:58:27,733 Trac[__init__] DEBUG: No policy allowed anonymous performing ROADMAP_VIEW on <Context '[root]'>
2007-10-03 14:58:27,749 Trac[__init__] DEBUG: No policy allowed anonymous performing SEARCH_VIEW on <Context '[root]'>
2007-10-03 14:58:27,765 Trac[__init__] DEBUG: No policy allowed anonymous performing REPORT_VIEW on <Context '[root]'>
2007-10-03 14:58:27,780 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context '[root]'>
2007-10-03 14:58:28,108 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x01BC2C50>>
2007-10-03 14:58:28,108 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_APPEND on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x01BC2C50>>
2007-10-03 14:58:28,140 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_APPEND on <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x024788F0>>
2007-10-03 14:58:28,140 Trac[__init__] DEBUG: LegacyAttachmentPolicy denied anonymous access to <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x024788F0>>. User needs TICKET_APPEND
2007-10-03 14:58:28,140 Trac[__init__] DEBUG: LegacyAttachmentPolicy denies anonymous performing ATTACHMENT_CREATE on <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x024788F0>>
2007-10-03 14:58:28,155 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CHGPROP on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x01BC2C50>>
2007-10-03 14:58:28,155 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x01BC2C50>>
2007-10-03 14:58:28,608 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5143'">
2007-10-03 14:58:28,655 Trac[__init__] WARNING: 404 Invalid Ticket Number (Ticket 5143 does not exist.)
2007-10-03 14:58:28,655 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:58:28,655 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context '[root]'>
2007-10-03 14:58:28,671 Trac[__init__] DEBUG: No policy allowed anonymous performing BROWSER_VIEW on <Context '[root]'>
2007-10-03 14:58:28,671 Trac[__init__] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Context '[root]'>
2007-10-03 14:58:28,671 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on <Context '[root]'>
2007-10-03 14:58:28,671 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on <Context '[root]'>
2007-10-03 14:58:28,687 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context '[root]'>
2007-10-03 14:58:28,687 Trac[__init__] DEBUG: No policy allowed anonymous performing TIMELINE_VIEW on <Context '[root]'>
2007-10-03 14:58:28,687 Trac[__init__] DEBUG: No policy allowed anonymous performing ROADMAP_VIEW on <Context '[root]'>
2007-10-03 14:58:28,687 Trac[__init__] DEBUG: No policy allowed anonymous performing SEARCH_VIEW on <Context '[root]'>
2007-10-03 14:58:28,701 Trac[__init__] DEBUG: No policy allowed anonymous performing REPORT_VIEW on <Context '[root]'>
2007-10-03 14:58:28,701 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context '[root]'>
2007-10-03 14:58:28,701 Trac[__init__] DEBUG: Retrieving session for ID 'fc8575b98d84b2acc60eba47'
2007-10-03 14:58:37,890 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5142'">
2007-10-03 14:58:37,951 Trac[__init__] DEBUG: Retrieving session for ID 'fc8575b98d84b2acc60eba47'
2007-10-03 14:58:37,951 Trac[__init__] DEBUG: Checking MUPPETS <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 14:58:37,951 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 14:58:37,951 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context '[root]'>
2007-10-03 14:58:37,967 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 14:58:37,967 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_MODIFY on <Context '[root]'>
2007-10-03 14:58:37,967 Trac[__init__] DEBUG: render_ticket_action_control: action "leave"
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing BROWSER_VIEW on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing TIMELINE_VIEW on <Context '[root]'>
2007-10-03 14:58:37,983 Trac[__init__] DEBUG: No policy allowed anonymous performing ROADMAP_VIEW on <Context '[root]'>
2007-10-03 14:58:37,999 Trac[__init__] DEBUG: No policy allowed anonymous performing SEARCH_VIEW on <Context '[root]'>
2007-10-03 14:58:37,999 Trac[__init__] DEBUG: No policy allowed anonymous performing REPORT_VIEW on <Context '[root]'>
2007-10-03 14:58:38,015 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context '[root]'>
2007-10-03 14:58:38,233 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x02BF8B50>>
2007-10-03 14:58:38,233 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_APPEND on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x02BF8B50>>
2007-10-03 14:58:38,249 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_APPEND on <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x02C0C2D0>>
2007-10-03 14:58:38,249 Trac[__init__] DEBUG: LegacyAttachmentPolicy denied anonymous access to <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x02C0C2D0>>. User needs TICKET_APPEND
2007-10-03 14:58:38,249 Trac[__init__] DEBUG: LegacyAttachmentPolicy denies anonymous performing ATTACHMENT_CREATE on <Context u'[root], ticket:5142, attachment' <Request "GET u'/ticket/5142'"> <trac.attachment.Attachment object at 0x02C0C2D0>>
2007-10-03 14:58:38,280 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CHGPROP on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x02BF8B50>>
2007-10-03 14:58:38,280 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'"> <trac.ticket.model.Ticket object at 0x02BF8B50>>
2007-10-03 14:58:38,437 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/css/trac.css'">
2007-10-03 14:58:38,640 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/css/ticket.css'">
2007-10-03 14:58:38,701 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/css/code.css'">
2007-10-03 14:58:38,749 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/js/jquery.js'">
2007-10-03 14:58:38,983 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/js/trac.js'">
2007-10-03 14:58:39,015 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/js/search.js'">
2007-10-03 14:58:39,046 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/js/wikitoolbar.js'">
2007-10-03 14:58:39,092 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/site/Intes-logo-tzz3.png'">
2007-10-03 14:58:39,092 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/trac_logo_mini.png'">
2007-10-03 14:58:39,108 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/topbar_gradient.png'">
2007-10-03 14:58:39,108 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/dots.gif'">
2007-10-03 14:58:39,108 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/feed.png'">
2007-10-03 14:58:39,233 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5143'">
2007-10-03 14:58:39,296 Trac[__init__] WARNING: 404 Invalid Ticket Number (Ticket 5143 does not exist.)
2007-10-03 14:58:39,296 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:58:39,296 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_CREATE on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing BROWSER_VIEW on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing TIMELINE_VIEW on <Context '[root]'>
2007-10-03 14:58:39,312 Trac[__init__] DEBUG: No policy allowed anonymous performing ROADMAP_VIEW on <Context '[root]'>
2007-10-03 14:58:39,326 Trac[__init__] DEBUG: No policy allowed anonymous performing SEARCH_VIEW on <Context '[root]'>
2007-10-03 14:58:39,326 Trac[__init__] DEBUG: No policy allowed anonymous performing REPORT_VIEW on <Context '[root]'>
2007-10-03 14:58:39,326 Trac[__init__] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on <Context '[root]'>
2007-10-03 14:58:39,326 Trac[__init__] DEBUG: Retrieving session for ID 'fc8575b98d84b2acc60eba47'
2007-10-03 14:59:08,858 Trac[__init__] DEBUG: Dispatching <Request "GET u'/chrome/common/expander_normal_hover.png'">
2007-10-03 14:59:11,717 Trac[__init__] DEBUG: Dispatching <Request "GET u'/login'">
2007-10-03 14:59:14,608 Trac[__init__] DEBUG: Dispatching <Request "GET u'/browser/trunk/DRIVE_Z/vvs-src/source'">
2007-10-03 14:59:15,733 Trac[__init__] DEBUG: Retrieving session for ID 'ulr1'
2007-10-03 14:59:15,937 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 14:59:16,217 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5142'">
2007-10-03 14:59:25,842 Trac[__init__] DEBUG: Checking MUPPETS <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 14:59:28,217 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 14:59:28,703 Trac[__init__] DEBUG: render_ticket_action_control: action "leave"
2007-10-03 14:59:28,842 Trac[__init__] DEBUG: render_ticket_action_control: action "resolve"
2007-10-03 14:59:29,905 Trac[__init__] DEBUG: render_ticket_action_control: action "reassign"
2007-10-03 14:59:30,842 Trac[__init__] DEBUG: Retrieving session for ID u'ulr1'
2007-10-03 14:59:30,937 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 15:00:25,453 Trac[__init__] DEBUG: Dispatching <Request "GET u'/login'">
2007-10-03 15:00:26,391 Trac[__init__] DEBUG: Retrieving session for ID 'ulr1'
2007-10-03 15:00:26,437 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5142'">
2007-10-03 15:00:28,546 Trac[__init__] DEBUG: Checking MUPPETS <Context u'[root], ticket:5142' <Request "GET u'/ticket/5142'">>
2007-10-03 15:00:28,733 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 15:00:28,733 Trac[__init__] DEBUG: render_ticket_action_control: action "leave"
2007-10-03 15:00:28,733 Trac[__init__] DEBUG: render_ticket_action_control: action "resolve"
2007-10-03 15:00:28,766 Trac[__init__] DEBUG: render_ticket_action_control: action "reassign"
2007-10-03 15:00:29,030 Trac[__init__] DEBUG: Retrieving session for ID u'ulr1'
2007-10-03 15:00:29,030 Trac[__init__] DEBUG: Prepare chrome data for request
2007-10-03 15:00:37,155 Trac[__init__] DEBUG: Dispatching <Request "GET u'/ticket/5062'">
2007-10-03 15:00:37,405 Trac[__init__] DEBUG: Checking MUPPETS <Context u'[root], ticket:5062' <Request "GET u'/ticket/5062'">>
2007-10-03 15:00:37,469 Trac[__init__] DEBUG: action controllers: [<trac.ticket.default_workflow.ConfigurableTicketWorkflow object at 0x014585D0>]
2007-10-03 15:00:37,469 Trac[__init__] DEBUG: render_ticket_action_control: action "leave"
2007-10-03 15:00:37,469 Trac[__init__] DEBUG: render_ticket_action_control: action "resolve"
2007-10-03 15:00:37,641 Trac[__init__] DEBUG: render_ticket_action_control: action "reassign"
2007-10-03 15:00:37,655 Trac[__init__] DEBUG: Retrieving session for ID u'ulr1'
2007-10-03 15:00:37,655 Trac[__init__] DEBUG: Prepare chrome data for request

Mmaybe is the conincidence, maybe not, but our trac 0.11dev (standalone+win32) became very slow after this and very memory dirsty (>250mb), i had to restart it. it reported lots of such errors: 

  File "z:\env-lib\python24\lib\site-packages\Trac-0.11dev_r6038-py2.4.egg\trac\web\wsgi.py", line 199, in _write
    self.handler.wfile.write(data)
  File "Z:\env-lib\PYTHON24\lib\socket.py", line 248, in write
    self.flush()
  File "Z:\env-lib\PYTHON24\lib\socket.py", line 235, in flush
    self._sock.sendall(buffer)
error: (10053, 'Software caused connection abort')

we use python 2.4.

by trebor74hr@…, 17 years ago

Attachment: login_session_prb1.png​ added

is this ok? every login produces new trac_auth, every logout new trac_session, old are not deleted

comment:5 by trebor74hr@…, 17 years ago

i tried to reproduce the strange session behavior with tracking cookies (firefox/options/privacy/show cookies).

since the cookie manager is independent of ff, and is updated immediately after cookie changes, it can be used for tracking. I deleted all cookies, what puts me in logout state, and then on clean state i started inducing the error.

i notified following (no error scenario):

  • empty
  • open the page →cookie is filled with some form and session
  • surf - no changes
  • login → new cookie auth
  • surf - no changes
  • logout → new cookie session (old preserved, so 2 session entries, and 1 auth)
  • surf → no changes
  • login → new cookie auth (old preserved, so 2 auth, and 2 session entries) …

so every logout generates new session, and every login new auth cookie. nothing is deleted. if you try to remove one cookie (e.g. auth) all auth cookies dissapear and for N-1 deleted cookie one blank cookie out of the folder is created (some kind of firefox unhandled state). if you remove auth cookies, since all auth dissapear, then you've been logged out. I send attachment that shows the case.

at the end i coudn't reproduce the error :(, but my collegue reproduced it (so it is stile alive), but with no cookie tracking, so no details.

comment:6 by David.Biesack@…, 17 years ago

I have been experiencing automatic session termination very frequently at ​https://projectfortress.sun.com/Projects/Community/wiki/ which is running Trac 0.10.3. It makes the site almost unusable. I do not know if this is related to mod_python (I do not know how the site is implemented). However, many operations fail. Often, when I edit a page then try to submit my changes, I get

editing a page, my session terminates and I get 

  Forbidden

WIKI_MODIFY privileges are required to perform this operation

In addition to this session termination problem:

  • issuing a BACK command in the browser to return to the edit window (after getting this Forbidden messages) loses all my edits; the edit area is reset the previous (saved) page content, not the text that I had edited.
  • logging in takes a long time, from 10 to 15 seconds.

comment:7 by Christian Boos, 17 years ago

Milestone: → 0.11.1

Would be worth investigating further.

in reply to:  6 comment:8 by trebor74hr@…, 17 years ago

Replying to David.Biesack@sas.com:

Hi again,

we have 2 trac installations, one on Linux+apache+py25+mod_python and one win32+py24+standalone. On win32+py24+standalone we don't have any of these problems. The trac version is the same, so cause should be in apache/mod_python/py25 (least probable). The cause can be like described in first post from cboos (​http://trac.edgewall.org/ticket/6121#comment:1).

I found the way to investigate the problem (as described in prev post), but since it is not critical for us, i'll do this later. The problem is probably because of some fault cookie managing. If you have the error constantly appearing, you can try tracing cookies like this:

  • start firefox
  • options/privacy/show cookies → new dialog Cookies
  • remove all cookis (if this is ok for you)
  • open trac page
  • watch what happens in cookies dialog (it is auto-refreshed)
  • login / do something / logout … try to reproduce the error and watch if cookies are changed ok

if you find something strange, please report it … Good luck ;)

I have been experiencing automatic session termination very frequently at ​https://projectfortress.sun.com/Projects/Community/wiki/ which is running Trac 0.10.3. It makes the site almost unusable. I do not know if this is related to mod_python (I do not know how the site is implemented). However, many operations fail. Often, when I edit a page then try to submit my changes, I get

editing a page, my session terminates and I get 

  Forbidden

WIKI_MODIFY privileges are required to perform this operation

In addition to this session termination problem:

  • issuing a BACK command in the browser to return to the edit window (after getting this Forbidden messages) loses all my edits; the edit area is reset the previous (saved) page content, not the text that I had edited.
  • logging in takes a long time, from 10 to 15 seconds.

comment:9 by anonymous, 17 years ago

Priority: high → lowest
Severity: major → minor

This seems to arise from having multiple connections to the internet going through the same router. In other words, if your ip address changes while you are logged in you lose your login info and you are not allowed to login again.

comment:10 by Christian Boos, 17 years ago

Can you have a look at #3211?

comment:11 by trebor74hr@…, 17 years ago

I think I found a workaround, but don't know the reason. It seems that web/auth.py has problem. I use auth by ip:

  • new session is created for logged user - insert into auth_cookie
  • commit
  • (i check in db and there is new entry for the user / ip)
  • select for sessionid from auth_cookie - NO RECORD FOUND'''
  • if no record - log out the user - send expired authcookie=

Note that delete from auth cookie table is not done, so after several unsuccessful logins i get for the same user/same ip lot of sessions in auth_cookie. It isn't allways like this, sometimes the

I tried to solve the problem with putting commit before select and it seems to be functioning (hadn't reproduced error since). I send workaround in attach. This happens only on ubuntu/apache/mod_python/trac configuration, on win32/standalone it doesn't happen. Don't really know why is this.

by trebor74hr@…, 17 years ago

Attachment: ticket_6121_workaround.diff​ added

workaround

by trebor74hr@…, 17 years ago

Attachment: ticket_6121_workaround2.diff​ added

workaround - try 2

by trebor74hr@…, 17 years ago

Attachment: ticket_6121_workaround2.2.diff​ added

workaround - try 2

comment:12 by anonymous, 17 years ago

don't know why diff is not shown good, i produced it by: hg diff > …

in reply to:  12 comment:13 by Christian Boos, 17 years ago

Replying to anonymous:

don't know why diff is not shown good, i produced it by: hg diff > …

The workaround2.diff files miss the file header that is present for the workaround.diff: 

diff -r 274c193231b9 trac/web/auth.py
--- a/trac/web/auth.py	Thu Nov 15 14:26:47 2007 +0100
+++ b/trac/web/auth.py	Wed Nov 21 17:40:45 2007 +0100
...

(support for git patches is improved a bit in 0.11 though)

comment:14 by ogradyj@…, 17 years ago

I'm going to report the same problem here. Description: User clicks "login" and gets the basic http-auth challenge popup. User types username and password and hits enter. User is successfully logged in. User clicks "logout". User seems to be logged out and has all rights associated with annonymous users. User clicks "login" again. No challenge popup and user is logged in again automatically. User closes down browser completely, restarts browser and clicks "login". Auth challenge box comes up again.

I've tried this on firefox and IE, latest versions of both. I've used every cookie manager I know to get rid of all cookies, session, stored, in-memory, and the results are the same. Unless the browser is restarted, the user is semi-permenently logged in and there is no way to log in as a different user.

Platform specs: CentOS4 Apache 2.2.6 apr 1.2.11 apr-util 1.2.10 mod_python 3.3.1 Python 2.5.1 trac trunk v6222

This is a really embarrasing bug, as I'm trying to get my current company to use this as I did my last (Comcast), and I can't even demo simple authentication. I know I'm dealing with the dev trunk here, but login problems???

in reply to:  14 comment:15 by ogradyj@…, 17 years ago

Replying to ogradyj@gsicommerce.com: Never mind. I found a really nice discussion that outlines why using HTTP basic auth is BAD.

​http://www.nabble.com/Why-my-trac-can-not-logout-t4726016.html

This information should be prominent in the TracGuide somewhere near the sections for setting up authentication. Also, you'd think that authorisation would be part of the main platform, and not a plugin? Surely logging in to a trac project can't be considered 3rd party functionality?

Bottom line, use AccountManagerPlugin:

​http://trac-hacks.org/wiki/AccountManagerPlugin

comment:16 by sid, 17 years ago

#6410 was marked as duplicate of this ticket.

comment:17 by Walsh , 17 years ago

Priority: lowest → normal

I'm using Windows environment to run trac and it's run in standalone server. I have a bad time with caching the authentication session in both FF and IE6. As an Eg. If I login as Abc using PW 1234 and then try to logout, then it display link but if i click on there there is no authentication required to login again. Simply the login window is not appearing it directly login to Trac. Can you all pls help me on this, How to solve this critical issue. Thank you very much

in reply to:  17 ; comment:18 by Emmanuel Blot, 17 years ago

Priority: normal → lowest

Replying to Walsh :

I'm using Windows environment to run trac and it's run in standalone server. I have a bad time with caching the authentication session in both FF and IE6. As an Eg. If I login as Abc using PW 1234 and then try to logout, then it display link but if i click on there there is no authentication required to login again. Simply the login window is not appearing it directly login to Trac. Can you all pls help me on this, How to solve this critical issue. Thank you very much

Your issue is not related to this ticket. You're facing the "HTTP authentication" issue. Search the Trac DB, the MailingList archive to find tips and workaround.

in reply to:  18 comment:19 by Emmanuel Blot, 17 years ago

Replying to eblot:

Replying to Walsh : Your issue is not related to this ticket. You're facing the "HTTP authentication" issue. Search the Trac DB, the MailingList archive to find tips and workaround.

#791, that is.

comment:20 by mika, 17 years ago

Cc: mladen@… added

I'm having the same problem. I keep getting logged out after a couple of clicks. I'm using 0.11b1, Python 2.5, Apache 2.0 on Win XP.

By the way - as I try to log this Akismet is giving me a problem. Pretty damn irritating.

in reply to:  9 comment:21 by guyer@…, 15 years ago

Replying to anonymous:

This seems to arise from having multiple connections to the internet going through the same router. In other words, if your ip address changes while you are logged in you lose your login info and you are not allowed to login again.

My IP address isn't changing while logged in. Everything is being done as localhost. I'm running Trac 0.11.6 under Apache 2.2.8 on a 10.5.8 Mac OS X machine, but had the same issues with 0.11rc2.

I've tried both mod_python and mod_wsgi and they both "forget" I'm logged in and the "login" link is missing. Sometimes repeatedly trying to load the same page gets it to "remember". Sometimes flushing Trac's cookies seems to help, or maybe it's just coincidence.

comment:22 by asheesh.agrawal@…, 15 years ago

Hey,

I am still getting the issue. My TRAC installation is getting repeatedely log out on performing login or submitting tickets. The behavior is seen in general, irrespective of whether the installation is run on FF/Chrome/IE.

It always dispalys Forbidden even though the user is having all the rights to play on.

comment:23 by mpapis@…, 14 years ago

in trac 0.12 setting auth_cookie_lifetime to 360000 helps a lot

in reply to:  23 comment:24 by mpapis@…, 14 years ago

Replying to mpapis@…:

in trac 0.12 setting auth_cookie_lifetime to 360000 helps a lot

Unfortunately this fixes only for some users, problem still appears, even after removing all plugins it breaks.

comment:25 by Christian Boos, 14 years ago

Milestone: next-minor-0.12.x
Resolution: → cantfix
Status: new → closed

I'm going to close this, as this ticket is likely not going any further.

In some cases it seems to be a genuine problem with Apache (comment:1), or perhaps in combination with mod_python. As mod_python is now unsupported, if people are experiencing this kind of issues, they should try to migrate to mod_wsgi.

In some other cases, this can be a problem with routers (comment:9, comment:10).

If anyone experience the same symptoms (spurious logouts) and it's not due to one of the above causes, then please open a new ticket, with all the appropriate information (how exactly this happens, what changes are observed in the cookies, etc.).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment
E-mail address and name can be saved in the Preferences .
Attachments ↑ Description ↑
 
Note: See TracTickets for help on using tickets.