Opened 12 years ago

Closed 10 years ago

# [patch] Infinite redirect loop after resetting the password

Reported by: Owned by: Georgi Georgiev Steffen Hoffmann normal AccountManagerPlugin major redirect 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@… 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
3. Logout

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

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 follow-up:  32 Changed 12 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:6 Changed 12 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 12 years ago by Noah Kantrowitz

Or more correctly:

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


### comment:9 Changed 12 years ago by cschnu

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

### comment:11 Changed 12 years ago by ryan@…

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

### Changed 12 years ago by ryan@…

coderanger's fix as a diff against the trunk r4132

### comment:14 follow-up:  15 Changed 12 years ago by vpolite@…

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 12 years ago by anonymous

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 12 years ago by David Rees

Cc: David Rees added changed from Matt Good to David Rees new → assigned

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

### comment:17 Changed 12 years ago by David Rees

Owner: changed from David Rees to Matt Good assigned → new

### comment:18 Changed 12 years ago by sh@…

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:20 Changed 12 years ago by anonymous

Can anybody provide a workaround for this problem?

### comment:22 Changed 12 years ago by blyth@…

I closed #4140 as it duplicates this

### comment:23 Changed 12 years ago by anonymous

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

why not solve it ?

### comment:24 Changed 12 years ago by brendan@…

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:26 Changed 12 years ago by anonymous

Priority: normal → highest

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:30 Changed 12 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:32 in reply to:  3 ; follow-ups:  35  38 Changed 12 years ago by anonymous

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 12 years ago by Paul Landolt

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 12 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 11 years ago by anonymous

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 11 years ago by anonymous

Resolution: → invalid new → closed

### comment:37 Changed 11 years ago by Georgi Georgiev

Resolution: invalid closed → reopened

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 11 years ago by anonymous

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

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:41 Changed 11 years ago by anonymous

Severity: normal → major

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:44 Changed 11 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 11 years ago by anonymous

I am also affected by this issue.

### comment:46 Changed 11 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 11 years ago by anonymous

another affected user. please fix this.

### comment:48 Changed 11 years ago by Jeff Hammel

can we fix this before the CC list gets longer?

### comment:49 Changed 11 years ago by Jeff Hammel

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

### comment:51 Changed 11 years ago by anonymous

Same problem here.

### comment:52 follow-up:  53 Changed 11 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 ; follow-up:  55 Changed 11 years ago by anonymous

Still in version installed for Trac 0.11.6 .

### comment:55 in reply to:  53 ; follow-up:  56 Changed 11 years ago by rachelle@…

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 11 years ago by cbidwell@…

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 11 years ago by John Hampton

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

### comment:58 Changed 11 years ago by John Hampton

Owner: changed from Matt Good to John Hampton reopened → new

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 11 years ago by John Hampton

Status: new → assigned

### comment:60 Changed 11 years ago by Adrian Fritz

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

### comment:61 Changed 11 years ago by anonymous

Cc: sh@… removed

### comment:63 in reply to:  62 ; follow-up:  66 Changed 10 years ago by henry@…

Severity: major → critical

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.

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

### comment:65 Changed 10 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 10 years ago by John Hampton

Resolution: → fixed assigned → closed

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.

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 follow-up:  74 Changed 10 years ago by cbidwell@…

Resolution: fixed critical → blocker closed → reopened

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 10 years ago by anonymous

Cc: mike.mclean@… removed

### comment:71 Changed 10 years ago by anonymous

Trac Release: 0.11 → 0.12

### comment:73 Changed 10 years ago by anonymous

Trac Release: 0.12 → 0.11

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

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

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 follow-up:  78 Changed 10 years ago by Steffen Hoffmann

Owner: changed from John Hampton to Steffen Hoffmann reopened → new

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 10 years ago by anonymous

Cc: kameron.larsen@… removed

### comment:77 Changed 10 years ago by Paul Landolt

Cc: plandolt@… removed

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

Keywords: needinfo added highest → high blocker → major Infinite redirect loop after resetting the password → [patch] Infinite redirect loop after resetting the password

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 follow-ups:  81  84 Changed 10 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

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

### comment:80 Changed 10 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 10 years ago by Steffen Hoffmann

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.

Per Firefox: The page isn't redirecting properly

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

### comment:82 follow-up:  83 Changed 10 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 10 years ago by Steffen Hoffmann

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 10 years ago by anonymous

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

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.

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 10 years ago by Steffen Hoffmann

Priority: high → normal

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 10 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 10 years ago by Steffen Hoffmann

Related T#9757 has been resolved.

### comment:87 Changed 10 years ago by Steffen Hoffmann

Resolution: → fixed new → closed

(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 10 years ago by Steffen Hoffmann

Keywords: needinfo removed

How to test/reproduce:

1. navigate to your Trac instance
3. fill in a user but no/invalid password
4. submit login form (-> authentication failed, redirects back to login page)
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 9 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 2 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