[patch] Infinite redirect loop after resetting the password

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!

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

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

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

Or more correctly:

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

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

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

coderanger's fix as a diff against the trunk r4132

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!

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.

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

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.

Can anybody provide a workaround for this problem?

I closed #4140 as it duplicates this

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

why not solve it ?

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

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

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

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

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'

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

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!

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.

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

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!

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.

I am also affected by this issue.

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.

another affected user. please fix this.

can we fix this before the CC list gets longer?

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

Same problem here.

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

Still in version installed for Trac 0.11.6 .

Replying to anonymous:

Still in version installed for Trac 0.11.6 .

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

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.

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

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.

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.

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

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.

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

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?

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?

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.

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.

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

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.

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.

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.

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?

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.

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

Related T#9757 has been resolved.

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

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.

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