Modify

Opened 16 years ago

Closed 13 years ago

Last modified 6 years ago

#3233 closed defect (fixed)

[patch] Infinite redirect loop after resetting the password

Reported by: Georgi Georgiev Owned by: Steffen Hoffmann
Priority: normal Component: AccountManagerPlugin
Severity: major Keywords: redirect
Cc: pioto@…, l-th@…, Chris Hoffman, Tim Jones, seva_fwd@…, cschnu, ryan@…, roh@…, vpolite@…, David Rees, bgladwell@…, cvhinten@…, brendan@…, billzingler@…, r.s.hatcher@…, foo.lim@…, ferringb@…, Brad Fritz, Felix, joshua@…, wenzel@…, Miguel, menderico@…, Jeff Hammel, naktinis@…, Scott, exarkun@…, henry@…, haterw@…, robison.sousa@… Trac Release: 0.11

Description

After resetting my password on Trac 0.11dev-r7189 (at http://trac.pioto.org/paludis/) I can no longer login. If I try to login with the new password I get in an infinite redirection loop (HTTP 302) to http://trac.pioto.org/paludis/prefs/account

I can only assume that this was introduced with the implementation of Ticket #1427.

I reproduced it by

  1. Creating a new account
  2. Login, post a comment on a ticket
  3. Logout
  4. Reset the password
  5. Try to login with the new password (I could not)

Attachments (1)

redirect-fix.patch (595 bytes) - added by ryan@… 16 years ago.
coderanger's fix as a diff against the trunk r4132

Download all attachments as: .zip

Change History (91)

comment:1 Changed 16 years ago by anonymous

Cc: pioto@… added; anonymous removed

comment:2 Changed 16 years ago by l-th@…

Cc: l-th@… added

I've seen this too.

I'm using Trac with FastCGI, and TRAC_ENV_PARENT_DIR (so that accessing http://trac.mysite.com produces a list of environments)

It is to do with #1427, I've tracked it down to web_ui.py line 188 (correct in r3832) which currently reads

if req.path_info != redirect_url:

In my case, req.path_info is being set to "/prefs/account" and redirect_url is being set to "/myprojectname/prefs/account". Hence they're different, and the redirect occurs again.

A quick fix to stop the redirect is to change that line to read

if not redirect_url.endswith(req.path_info):

Howevever, making it correctly incorporate (or strip) the project name would be better!

comment:3 Changed 16 years ago by Chris Hoffman

I'm also seeing this, and hastily logged #3354, which I suppose someone can resolve as a duplicate now.

I fixed the problem by turning off force_change_passwd, like so

[account-manager] force_change_passwd = false

comment:4 Changed 16 years ago by Chris Hoffman

Cc: Chris Hoffman added

comment:5 Changed 16 years ago by Tim Jones

Cc: Tim Jones added

comment:6 Changed 16 years ago by anonymous

I think line 188 in web_ui.py should actually look like this:

if req.base_path + req.path_info != redirect_url:

comment:7 Changed 16 years ago by Noah Kantrowitz

Or more correctly:

if req.href(req.path_info) != redirect_url:

comment:8 Changed 16 years ago by anonymous

Cc: seva_fwd@… added

comment:9 Changed 16 years ago by cschnu

I encountered this as well, will this fix be in the next build of this plugin?

comment:10 Changed 16 years ago by cschnu

Cc: cschnu added

comment:11 Changed 16 years ago by ryan@…

Cc: ryan@… added

I also encounter this error, coderanger's change worked for me.

Changed 16 years ago by ryan@…

Attachment: redirect-fix.patch added

coderanger's fix as a diff against the trunk r4132

comment:12 Changed 16 years ago by anonymous

Cc: roh@… added

comment:13 Changed 16 years ago by anonymous

Cc: mike.mclean@… added

comment:14 Changed 16 years ago by vpolite@…

Cc: vpolite@… added

Hey Ryan, I made an attempt at implementing coderanger's patch on my instance of Trac. I still get the redirect when I attempt to login after changing my password.

I updated the source code and did an easy_install against my new information. I verified the change by unzipping the resultant .egg file and noted the change was there. I removed session_attribute information and even played with toggling the force_password = false flag (which works, but you also have to remove the session_attribute associated with your account --- if it was set to force_password = true and isn't removed, then you get the redirect blues all over again)

What information can I provide that might assist in troubleshooting? Also, my python is not good, but shouldn't the conditional in the patch refer to when the ForceAccount flag is set to True, not False?

i.e.

186	186	            if req.session.get('force_change_passwd', False):

should be

186	186	            if req.session.get('force_change_passwd', True): 

Adding myself to the cc: list. Thanks!

comment:15 in reply to:  14 Changed 15 years ago by anonymous

Replying to vpolite@socialnetconnect.com:

What information can I provide that might assist in troubleshooting?

I am pretty unfamiliar with trac plugin development, and ended up getting help to install my patched version, and I now forget what I did to get the patch installed. I do recall having to restart apache. I'm afraid I'm not going to be much help in troubleshooting.

Also, my python is not good, but shouldn't the conditional in the patch refer to when the ForceAccount flag is set to True, not False?

I think the second parameter there is what to use as a default value in case 'force_change_passwd' is not found in req.session. If there's nothing specified, we assume we don't need to force the password change.

comment:16 Changed 15 years ago by David Rees

Cc: David Rees added
Owner: changed from Matt Good to David Rees
Status: newassigned

The patch seems to fix the issue for me using Trac 0.11.1. Any chance to see the fix committed?

comment:17 Changed 15 years ago by David Rees

Owner: changed from David Rees to Matt Good
Status: assignednew

comment:18 Changed 15 years ago by sh@…

Cc: sh@… added

I deeply hope that the patch (or any solution at all) finds the way in the distribution.

I am adding myself to the cc to be informed when something happens here.

PS: I am too dump to create an egg-file including the patch. So I guess I'll have to wait.

comment:19 Changed 15 years ago by anonymous

Cc: bgladwell@… added

comment:20 Changed 15 years ago by anonymous

Can anybody provide a workaround for this problem?

comment:21 Changed 15 years ago by anonymous

Cc: cvhinten@… added

comment:22 Changed 15 years ago by blyth@…

I closed #4140 as it duplicates this

comment:23 Changed 15 years ago by anonymous

I still encountered this , using tracaccountmanager-0.2.1dev_r4679-py2.5.egg

why not solve it ?

comment:24 Changed 15 years ago by brendan@…

Cc: brendan@… added

My users get into this state occasionally. It seems to correspond to this kind of entry in trac.log:

2009-01-09 06:52:39,043 Trac[session] WARNING: Session xxx already exists: database is locked

I suspect something is going wrong here, in web_ui.py:

                if force_change_password:
                    del(req.session['force_change_passwd'])
                    req.session.save()

Just guessing, but I wonder what happens if req.session.save() fails (in my case because the sqlite db is temporarily locked)?

comment:25 Changed 15 years ago by anonymous

Cc: billzingler@… added

comment:26 Changed 15 years ago by anonymous

Priority: normalhighest

Hey all,

I am using Trac 0.11.2.1, I can't find the "acct_mgr/web_ui.py" to modify, e.g.

locate acct_mgr
>> nothing found

Damn it...I am locked at this stage for 2 days...

comment:27 Changed 15 years ago by anonymous

Cc: r.s.hatcher@… added

comment:28 Changed 15 years ago by anonymous

Cc: kameron.larsen@… added

comment:29 Changed 15 years ago by anonymous

Cc: foo.lim@… added

comment:30 Changed 15 years ago by anonymous

The patch worked for me with the following steps

# Modify the source 
http://trac-hacks.org/attachment/ticket/3233/redirect-fix.patch
cd .../trac_accountmanagerplugin_0_11/
emacs acct_mgr/web_ui.py

# Build and reinstall
python setup.py install

# Restart web server (forgot this)
service httpd restart

/Lars

comment:31 Changed 15 years ago by anonymous

Cc: ferringb@… added

comment:32 in reply to:  3 ; Changed 15 years ago by anonymous

Replying to hoffmanc:

I fixed the problem by turning off force_change_passwd, like so

[account-manager] force_change_passwd = false

If you do this, you may still be stuck with the force_change_passwd set for some users in the trac.db. This flag can be cleared with:

sqlite3 yourtrac/db/trac.db \ 'DELETE FROM "session_attribute" WHERE "name" = "force_change_passwd";'

then you are only left with a 'already logged in warning' and after that everything is fine again...

comment:33 Changed 15 years ago by Paul Landolt

Cc: plandolt@… added
Keywords: redirect added

I am having similar problems with Trac v0.11.4, Apache2 (mod_python), Postgres 8.X

I can see some of the pages, but I get into a Redirect Loop for the following pages: Wiki, Timeline, Search, Admin

Strangely enough, I can edit Wiki pages without any problems.

I have gone through the patch information above. There is no longer any code references to 'force_change_passwd' that I can see, or any file 'acct_mgr/web_ui.py'

comment:34 Changed 15 years ago by Paul Landolt

Forgot to mention that all of the page links work without incident under tracd. And I recently installed the AccountManager plugin, but 'Admin' still has the Redirect Loop

comment:35 in reply to:  32 Changed 15 years ago by anonymous

Replying to anonymous:

Replying to hoffmanc:

I fixed the problem by turning off force_change_passwd, like so

[account-manager] force_change_passwd = false

If you do this, you may still be stuck with the force_change_passwd set for some users in the trac.db. This flag can be cleared with:

sqlite3 yourtrac/db/trac.db \ 'DELETE FROM "session_attribute" WHERE "name" = "force_change_passwd";'

then you are only left with a 'already logged in warning' and after that everything is fine again...

You are the man!

comment:36 Changed 15 years ago by anonymous

Resolution: invalid
Status: newclosed

comment:37 Changed 15 years ago by Georgi Georgiev

Resolution: invalid
Status: closedreopened

WTF? anonymous closing tickets!?

http://trac.pioto.org/paludis/ which is where I originally reported this problem against is now "Powered by Trac 0.11.5stable-r8061" and still has this problem.

comment:38 in reply to:  32 Changed 15 years ago by anonymous

I can confirm the bug. Thanks to the sqlite3 command it again is working.

Replying to anonymous:

Replying to hoffmanc:

I fixed the problem by turning off force_change_passwd, like so

[account-manager] force_change_passwd = false

If you do this, you may still be stuck with the force_change_passwd set for some users in the trac.db. This flag can be cleared with:

sqlite3 yourtrac/db/trac.db \ 'DELETE FROM "session_attribute" WHERE "name" = "force_change_passwd";'

then you are only left with a 'already logged in warning' and after that everything is fine again...

comment:39 Changed 15 years ago by anonymous

Cc: Brad Fritz added

comment:40 Changed 15 years ago by anonymous

Cc: Felix added

comment:41 Changed 15 years ago by anonymous

Severity: normalmajor

Guys, please get this fixed.

coderanger posted a (possible) fix for this on 07/17/08 already and this is a real bugger (and easy to fix).

I've been running into this for the second time now, and it basically makes the corresponding trac instance unusable for you!

comment:42 Changed 14 years ago by anonymous

Cc: joshua@… added

comment:43 Changed 14 years ago by anonymous

Cc: wenzel@… added

comment:44 Changed 14 years ago by anonymous

Thank you, setting [account-manager] force_change_passwd = false and deleting entries from the MySQL-Db ( DELETE FROM "session_attribute" WHERE name = 'force_change_passwd';) did the trick for me using Trac 0.11.5 and TracAccountManager 0.2.1dev-r5836.

comment:45 Changed 14 years ago by anonymous

Cc: Miguel added

I am also affected by this issue.

comment:46 Changed 14 years ago by Dawid DeyV Polak

The problem generate file:

TracActountManager/acct_mgr/web_ui.py in line ~200 - r5837 - trunk

                if req.path_info != redirect_url:
                    req.redirect(redirect_url)

After comment this 2 line problem gone.

comment:47 Changed 14 years ago by anonymous

another affected user. please fix this.

comment:48 Changed 14 years ago by Jeff Hammel

Cc: Jeff Hammel added

can we fix this before the CC list gets longer?

comment:49 Changed 14 years ago by Jeff Hammel

(In [7114]) disable force_passwd_change, see #3233

comment:50 Changed 14 years ago by anonymous

Cc: menderico@… added

comment:51 Changed 14 years ago by anonymous

Cc: naktinis@… added

Same problem here.

comment:52 Changed 14 years ago by oneill+trac@…

Confirm this is still in issue in most Trac v0.11.4, account manager from 0.11 branch svn.

Confirm that the patch 'redirect-fix' posted above works. This is not a force_passwd_change configuration issue

comment:53 in reply to:  52 ; Changed 14 years ago by anonymous

Still in version installed for Trac 0.11.6 .

comment:54 Changed 14 years ago by Scott

Cc: Scott added

comment:55 in reply to:  53 ; Changed 14 years ago by rachelle@…

Replying to anonymous:

Still in version installed for Trac 0.11.6 .

Ran into this same issue over the weekend. (0.11.6)

comment:56 in reply to:  55 Changed 14 years ago by cbidwell@…

Replying to rachelle@zealousconsulting.com:

Replying to anonymous:

Still in version installed for Trac 0.11.6 .

Ran into this same issue over the weekend. (0.11.6)

Anyone have a permanent fix for this problem? This seems to be the most recurring issue that I have with trac and my users.

comment:57 Changed 14 years ago by John Hampton

(In [7721]) Applied patch to avoid infinite redirect when using forced password changes. References #3233

comment:58 Changed 14 years ago by John Hampton

Owner: changed from Matt Good to John Hampton
Status: reopenednew

I applied the patch. It works for my limited testing. Please upgrade to the latest trunk and test. I will close this ticket next week if there are no more complaints of this occurring.

comment:59 Changed 14 years ago by John Hampton

Status: newassigned

comment:60 Changed 14 years ago by Adrian Fritz

Summary: Infinite redirect loop after resetting the password[Patch] Infinite redirect loop after resetting the password

comment:61 Changed 14 years ago by anonymous

Cc: sh@… removed

comment:62 Changed 14 years ago by anonymous

Cc: exarkun@… added

comment:63 in reply to:  62 ; Changed 14 years ago by henry@…

Severity: majorcritical

Replying to anonymous:

Got the same problem now... after password change, loops at

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

chrome reports the same.

cookies are enabled.

This makes trac unusable for me or any user it happens to.

comment:64 Changed 14 years ago by anonymous

Cc: henry@… added

comment:65 Changed 14 years ago by David Rees

Updated to the latest on the 0.11 branch - works for me, thanks!

comment:66 in reply to:  63 Changed 14 years ago by John Hampton

Resolution: fixed
Status: assignedclosed

Replying to henry@bostontechnologies.com:

Replying to anonymous:

Got the same problem now... after password change, loops at

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

chrome reports the same.

cookies are enabled.

This makes trac unusable for me or any user it happens to.

So, if you update to the latest 0.11 or even trunk, does this still happen? Your subversion revision should be at least [7721]

I am closing this ticket as it looks like the fix worked for others. If you update and it still doesn't work, please re-open the ticket.

comment:67 Changed 14 years ago by cbidwell@…

Resolution: fixed
Severity: criticalblocker
Status: closedreopened

Just updated to latest SVN build Trac==0.11.7.1dev-r9726 and still get "The page isn't redirecting properly" on Firefox.

comment:69 Changed 14 years ago by anonymous

Cc: mike.mclean@… removed

comment:70 Changed 14 years ago by anonymous

Cc: haterw@… added

comment:71 Changed 14 years ago by anonymous

Trac Release: 0.110.12

comment:72 Changed 14 years ago by anonymous

Cc: robison.sousa@… added

comment:73 Changed 14 years ago by anonymous

Trac Release: 0.120.11

comment:74 in reply to:  67 Changed 14 years ago by Steffen Hoffmann

Summary: [Patch] Infinite redirect loop after resetting the passwordInfinite redirect loop after resetting the password

Replying to cbidwell@usgs.gov:

Just updated to latest SVN build Trac==0.11.7.1dev-r9726 and still get "The page isn't redirecting properly" on Firefox.

Wow, never seen such a long Cc-list before.

Anyway, while testing I've trigger an unbreakable loop myself now with current trunk version and Trac 0.12. So we need more ideas, right?

comment:75 Changed 13 years ago by Steffen Hoffmann

Owner: changed from John Hampton to Steffen Hoffmann
Status: reopenednew

After [9263] I can't reproduce the infinite loop anymore, but in the first test a new user was redirected to nowhere the first time he/she entered Trac. Anyway two more tests went through without any problem. Slight progress? Finally the fix? Think so. More testers? Comments?

comment:76 Changed 13 years ago by anonymous

Cc: kameron.larsen@… removed

comment:77 Changed 13 years ago by Paul Landolt

Cc: plandolt@… removed

comment:78 in reply to:  75 Changed 13 years ago by Steffen Hoffmann

Keywords: needinfo added
Priority: highesthigh
Severity: blockermajor
Summary: Infinite redirect loop after resetting the password[patch] Infinite redirect loop after resetting the password

Replying to hasienda:

After [9263] I can't reproduce the infinite loop anymore, but in the first test a new user was redirected to nowhere the first time he/she entered Trac. Anyway two more tests went through without any problem. Slight progress? Finally the fix? Think so. More testers? Comments?

My suggestion is supported by #1382. The patch attached there contains identical code to what has already been added with changeset [7721].

Therefore I lower priority right now. If there are no more complaints raised here, I'll even be reluctant to keep this ticket open for a much longer time.

comment:79 Changed 13 years ago by anonymous

I get this with the current stable install on ubuntu Lucid following the directions here: http://192.168.0.116/trac/wiki/TracCgi

Version: Welcome to trac-admin 0.11.7

Per Firefox: The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

  • This problem can sometimes be caused by disabling or refusing to accept

cookies.

comment:80 Changed 13 years ago by anonymous

PS: After I logged in (using Konqueror) for the first time I could no longer reproduce on Firefox. FF version = 3.5.10

comment:81 in reply to:  79 Changed 13 years ago by Steffen Hoffmann

Replying to anonymous:

I get this with the current stable install on ubuntu Lucid following the directions here: http://192.168.0.116/trac/wiki/TracCgi

You don't expect us to follow the link, do you? This is a private address, accessible only from with (your) LAN.

Version: Welcome to trac-admin 0.11.7

Per Firefox: The page isn't redirecting properly

Well, please have a look at #3783 as well, as that might be related.

comment:82 Changed 13 years ago by robisoncleyton

I'm sorry, but I write english not very well.

The infinite redirect loop happens because force_passwd_change option is cleared.

So, check the option false in menu Account Manager or change the trac.ini file .

I hope that helps.

comment:83 in reply to:  82 Changed 13 years ago by Steffen Hoffmann

Replying to robisoncleyton:

I'm sorry, but I write english not very well.

The infinite redirect loop happens because force_passwd_change option is cleared.

So, check the option false in menu Account Manager or change the trac.ini file .

I hope that helps.

No, sorry. I've done a quick test unchecking the option, but this does no harm. But maybe I've just misunderstood. Would you please explain in more details, how to reproduce (provided you're able to test recent trunk code). I'm very interested in fixing any bad behavior, if still existent.

comment:84 in reply to:  79 Changed 13 years ago by anonymous

Replying to anonymous:

  • This problem can sometimes be caused by disabling or refusing to accept

cookies.

If this is unrelated, please overlook my post ;). However, I ran into problems with logging in when using Internet Explorer 6. After (correctly) authenticating, I would be redirected back to the login page, as if I had not authenticated at all.

It turned out that (in my case) IE was rejecting the trac session cookies because the Apache server was not publishing an appropriate P3P policy. Once I added an appropriate policy to my Apache configuration it worked.

I don't have access to the server now, but I think I added something like:

Header set P3P "policyref=\"/w3c/p3p.xml\", CP=\"NOI DSP COR NID CUR ADM DEV OUR BUS\""

from here (You can interpret the codes using this page, for example)

Perhaps this is something else to try for those that are still having issues?

comment:85 Changed 13 years ago by Steffen Hoffmann

Priority: highnormal

I'll keep this ticket open for a while, but lower priority, at least as long as I can't see certain demand for action.

comment:85 Changed 13 years ago by Steffen Hoffmann

(In [9404]) AccountManagerPlugin: Provide fallback for undefined HTTP referer after successful login attempt, closes #3783, refs #3233 and #7687.

Redirect to corresponding Trac project's base URL, if referrer is undefined. We prefer req.abs_href() over req.base_url, as a req object is available and should always contain the needed information even with option base_url unset in trac.ini . See T#5064 for even more details.

comment:86 Changed 13 years ago by Steffen Hoffmann

Related T#9757 has been resolved.

comment:87 Changed 13 years ago by Steffen Hoffmann

Resolution: fixed
Status: newclosed

(In [9515]) AccountManagerPlugin: Break redirect loop in LoginModule, closes #3233.

Found by investigating interaction between LoginModule and auth.LoginModule from Trac, confirmed loop condition, and this is the simple but certainly non-trivial fix. Enjoy.

comment:88 Changed 13 years ago by Steffen Hoffmann

Keywords: needinfo removed

How to test/reproduce:

  1. navigate to your Trac instance
  2. call AccountManagerPlugin's own login page via 'login' link in metanav
  3. fill in a user but no/invalid password
  4. submit login form (-> authentication failed, redirects back to login page)
  5. call AccountManagerPlugin's own login page via 'login' link in metanav again (now we have /login set as the HTTP referrer)
  6. fill in valid user and password
  7. watch endless loop back to login right after submitting login form

With the patch applied in changeset [9515] this gets cleared and previous fixes for other loop/invalid referrer issue remains functional. I'm not aware of any remaining similar occurrence of invalid redirects. Please test yourself.

comment:89 Changed 13 years ago by Steffen Hoffmann

(In [10421]) AccountManagerPlugin: Second: Improve redirect loop protection - again, refs #3233 and #8963.

We already knew a lot about infinite loops starting from '/login' (see #3233), but for Trac 0.11 obviously this has been not enough. Still I wonder, why no one complained about it recently.

Hint: Trac 0.11 doesn't preserve the referer very well, but I'm reluctant to fix this in AccountManager. Better use a current Trac, if you dislike it.

comment:90 Changed 6 years ago by Ryan J Ollos

In 17228:

TracAccountManager 0.5.1dev: Remove compatibility code

Trac < 1.0 is no longer supported. This reverts r10421.

Refs #3233, #8963.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Steffen Hoffmann.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.