Modify

Opened 6 years ago

Closed 4 years ago

Last modified 3 years ago

#3233 closed defect (fixed)

[patch] Infinite redirect loop after resetting the password

Reported by: chutz Owned by: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: major Keywords: redirect
Cc: pioto@…, l-th@…, hoffmanc, chris.c.hoffman@…, timothy.jones@…, seva_fwd@…, csch_nu@…, ryan@…, roh@…, vpolite@…, drees@…, bgladwell@…, cvhinten@…, brendan@…, billzingler@…, r.s.hatcher@…, foo.lim@…, ferringb@…, brad-trachacks@…, snoopotic@…, joshua@…, wenzel@…, miguel@…, menderico@…, k0s, naktinis@…, sahendrickson, 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@… 6 years ago.
coderanger's fix as a diff against the trunk r4132

Download all attachments as: .zip

Change History (90)

comment:1 Changed 6 years ago by anonymous

  • Cc pioto@… added

comment:2 Changed 6 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 follow-up: Changed 6 years ago by hoffmanc

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 6 years ago by hoffmanc

  • Cc hoffmanc chris.c.hoffman@… added

comment:5 Changed 6 years ago by tjones

  • Cc timothy.jones@… added

comment:6 Changed 6 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 6 years ago by coderanger

Or more correctly:

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

comment:8 Changed 6 years ago by anonymous

  • Cc seva_fwd@… added

comment:9 Changed 6 years ago by cschnu

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

comment:10 Changed 6 years ago by cschnu

  • Cc csch_nu@… added

comment:11 Changed 6 years ago by ryan@…

  • Cc ryan@… added

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

Changed 6 years ago by ryan@…

coderanger's fix as a diff against the trunk r4132

comment:12 Changed 6 years ago by anonymous

  • Cc roh@… added

comment:13 Changed 6 years ago by anonymous

  • Cc mike.mclean@… added

comment:14 follow-up: Changed 6 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 6 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 6 years ago by drees

  • Cc drees@… added
  • Owner changed from mgood to drees
  • Status changed from new to 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 6 years ago by drees

  • Owner changed from drees to mgood
  • Status changed from assigned to new

comment:18 Changed 6 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 6 years ago by anonymous

  • Cc bgladwell@… added

comment:20 Changed 6 years ago by anonymous

Can anybody provide a workaround for this problem?

comment:21 Changed 6 years ago by anonymous

  • Cc cvhinten@… added

comment:22 Changed 6 years ago by blyth@…

I closed #4140 as it duplicates this

comment:23 Changed 6 years ago by anonymous

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

why not solve it ?

comment:24 Changed 6 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 6 years ago by anonymous

  • Cc billzingler@… added

comment:26 Changed 6 years ago by anonymous

  • Priority changed from normal to 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:27 Changed 6 years ago by anonymous

  • Cc r.s.hatcher@… added

comment:28 Changed 6 years ago by anonymous

  • Cc kameron.larsen@… added

comment:29 Changed 6 years ago by anonymous

  • Cc foo.lim@… added

comment:30 Changed 6 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 6 years ago by anonymous

  • Cc ferringb@… added

comment:32 in reply to: ↑ 3 ; follow-ups: Changed 5 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 5 years ago by 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 5 years ago by 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 5 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 5 years ago by anonymous

  • Resolution set to invalid
  • Status changed from new to closed

comment:37 Changed 5 years ago by chutz

  • Resolution invalid deleted
  • Status changed from closed to 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 5 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 5 years ago by anonymous

  • Cc brad-trachacks@… added

comment:40 Changed 5 years ago by anonymous

  • Cc snoopotic@… added

comment:41 Changed 5 years ago by anonymous

  • Severity changed from normal to major

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

  • Cc joshua@… added

comment:43 Changed 5 years ago by anonymous

  • Cc wenzel@… added

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

  • Cc miguel@… added

I am also affected by this issue.

comment:46 Changed 5 years ago by Dawid@…

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

another affected user. please fix this.

comment:48 Changed 5 years ago by k0s

  • Cc k0s added

can we fix this before the CC list gets longer?

comment:49 Changed 5 years ago by k0s

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

comment:50 Changed 5 years ago by anonymous

  • Cc menderico@… added

comment:51 Changed 5 years ago by anonymous

  • Cc naktinis@… added

Same problem here.

comment:52 follow-up: Changed 5 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: Changed 5 years ago by anonymous

Still in version installed for Trac 0.11.6 .

comment:54 Changed 5 years ago by sahendrickson

  • Cc sahendrickson added

comment:55 in reply to: ↑ 53 ; follow-up: Changed 5 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 5 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 5 years ago by pacopablo

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

comment:58 Changed 5 years ago by pacopablo

  • Owner changed from mgood to pacopablo
  • Status changed from reopened to 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 5 years ago by pacopablo

  • Status changed from new to assigned

comment:60 Changed 5 years ago by AdrianFritz

  • Summary changed from Infinite redirect loop after resetting the password to [Patch] Infinite redirect loop after resetting the password

comment:61 Changed 5 years ago by anonymous

  • Cc sh@… removed

comment:62 follow-up: Changed 5 years ago by anonymous

  • Cc exarkun@… added

comment:63 in reply to: ↑ 62 ; follow-up: Changed 4 years ago by henry@…

  • Severity changed from major to critical

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

  • Cc henry@… added

comment:65 Changed 4 years ago by drees

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

comment:66 in reply to: ↑ 63 Changed 4 years ago by pacopablo

  • Resolution set to fixed
  • Status changed from assigned to closed

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

  • Resolution fixed deleted
  • Severity changed from critical to blocker
  • Status changed from closed to 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 4 years ago by anonymous

  • Cc mike.mclean@… removed

comment:70 Changed 4 years ago by anonymous

  • Cc haterw@… added

comment:71 Changed 4 years ago by anonymous

  • Trac Release changed from 0.11 to 0.12

comment:72 Changed 4 years ago by anonymous

  • Cc robison.sousa@… added

comment:73 Changed 4 years ago by anonymous

  • Trac Release changed from 0.12 to 0.11

comment:74 in reply to: ↑ 67 Changed 4 years ago by hasienda

  • Summary changed from [Patch] Infinite redirect loop after resetting the password to Infinite 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 follow-up: Changed 4 years ago by hasienda

  • Owner changed from pacopablo to hasienda
  • Status changed from reopened to 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 4 years ago by anonymous

  • Cc kameron.larsen@… removed

comment:77 Changed 4 years ago by landoltjp

  • Cc plandolt@… removed

comment:78 in reply to: ↑ 75 Changed 4 years ago by hasienda

  • Keywords needinfo added
  • Priority changed from highest to high
  • Severity changed from blocker to major
  • Summary changed from Infinite redirect loop after resetting the password to [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 follow-ups: Changed 4 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 4 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 4 years ago by hasienda

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 follow-up: Changed 4 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 4 years ago by hasienda

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 4 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 4 years ago by hasienda

  • Priority changed from high to 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 4 years ago by hasienda

(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 4 years ago by hasienda

Related T#9757 has been resolved.

comment:87 Changed 4 years ago by hasienda

  • Resolution set to fixed
  • Status changed from new to 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 4 years ago by hasienda

  • 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 3 years ago by hasienda

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.