After redirecting to the login screen, trac always loads the default page.

This is due to how the HTTP referer header works with redirects. Unfortunately there isn't much I can do.

Proposed fix

I've attached a patch for a fix. When you request a page and fail authentication, it sets a cookie to the URL you asked for. A wrapper around LoginModule._redirect_back adjusts the Referer header if it finds that cookie. _redirect_back then redirects back to the original page if authentication succeeds.

I couldn't get your patch file to apply to v0.11 of PermRedirectPlugin - I think the line numbering might be out?

Hmm... no, I think your patch must be for an earlier version.

Replying to anonymous:

Hmm... no, I think your patch must be for an earlier version.

It's a patch for 0.10 - you'll have to write your own patch for 0.11

This could now be fixed by using the referer= argument to /login, added to Trac 0.11-stable in [T7493].

Hi, Sir,

If you can provide a patch for 0.11 independently? We don't want to update the Trac, only want the the redirect problem fix. I searched but can't find the patch down. THanks in advance.

Bill

Patch to the 0.11 branch to use the referer querystring parameter

The patch I added above implements what rblank referred to in comment:6

After implement the PermRedirect?-urlfix.diff , I got this. I am not developer, could you check what it is please?

Oops...

Trac detected an internal error: invalid syntax (filter.py, line 27)

Traceback (most recent call last):

File "/usr/lib/python2.4/site-packages/trac/admin/templates/deploy_trac.cgi", line 27, in ?

cgi_frontend.run()

File "/usr/lib/python2.4/site-packages/trac/web/cgi_frontend.py", line 71, in run

gateway.run(dispatch_request)

File "/usr/lib/python2.4/site-packages/trac/web/wsgi.py", line 87, in run

response = application(self.environ, self._start_response)

File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 381, in dispatch_request

env = open_environment(env_path, use_cache=not run_once)

File "/usr/lib/python2.4/site-packages/trac/env.py", line 571, in open_environment

env = Environment(env_path)

File "/usr/lib/python2.4/site-packages/trac/env.py", line 185, in init

load_components(self, plugins_dir and (plugins_dir,))

File "/usr/lib/python2.4/site-packages/trac/loader.py", line 108, in load_components

loadfunc(env, search_path, auto_enable=plugins_dir)

File "/usr/lib/python2.4/site-packages/trac/loader.py", line 65, in _load_eggs

entry.load(require=True)

File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 1912, in load

entry = import(self.module_name, globals(),globals(), __name__?)

File "/usr/lib/python2.4/site-packages/permredirect/filter.py", line 27

login_url = req.href.login(referer=req.base_url + req.path_info)

SyntaxError?: invalid syntax

I am using AccountManager, so can't load trac.web.auth LoginModule? in your first patch. If this will have problem for your new patch?

Bill

Replying to Bill :

After implement the PermRedirect?-urlfix.diff , I got this. I am not developer, could you check what it is please?

   File "/usr/lib/python2.4/site-packages/permredirect/filter.py", line 27
      login_url = req.href.login(referer=req.base_url + req.path_info)
      ^
  SyntaxError: invalid syntax

Not too sure here; the best I can suggest is to check the syntax in the resulting file, maybe the patch applied incorrectly? I inserted that line 27 ('login_url...') in the patch, make sure it is indented the same as the line above('exctype...') and below it('if...').

Replying to anonymous:

I am using AccountManager, so can't load trac.web.auth LoginModule? in your first patch. If this will have problem for your new patch? Bill

The two patches proposed here are entirely independent. If you have already applied attachment:permredirect.diff you should get a clean version(I have this one) of PermRedirectPlugin before applying attachment:PermRedirect-urlfix.diff. I don't reference LoginModule? anywhere in this code; other dependencies/incompatibilities I don't know anything about.

I have rechecked the /usr/lib/python2.4/site-packages/permredirect/filter.py and sure it is same with your PermRedirect?-urlfix.diff.

Before when I search for this problem, I did see one patch for AccountManager plugin. But that patch was old and didn't work ( I tested by myself).

PermRedirect? plugin should fix this problem, that is why I installed it, but still have some problem. If anyone in your group and help to figure this out? Thanks anyway.

Bill

I can confirm that the PermRedirect?-urlfix.diff patch works like a charm for 0.11. What is needed to have this applied to the repository? Can I assist in any way?

Patch to the 0.11 branch to use the referer querystring parameter (now slightly improved to also capture the querystring of the original request instead of just the request path).

Is there any change for this patch to be included in Trac trunk ? If not, why ?

I am using Trac trunk (0.12dev) and have a similar problem : the redirect is not necessarily to the start page but if you were in an "edit" page (wiki edit, ticket modification) and when submitting your changes a perm redirect occurs, the modification is lost and you have to reapply it.

If you think this is not the same problem, I'll open a new ticket.

Cheers,

Michel

The situation you describe doesn't make any sense though, since there is no permission check that could fail at that time that wouldn't fail when opening the edit screen (unless you manually delete the auth cookie I suppose).

Replying to jouvin@lal.in2p3.fr:

Is there any change for this patch to be included in Trac trunk ? If not, why ?

I made the patch against browser:permredirectplugin/0.11#4929 running against trac version 0.11stable-r7510 (from about). I was just able to update my permredirectplugin checkout to browser:permredirectplugin/0.11#5162 (doesn't appear to be any changes). We've been using this for the past couple of months and are very happy with it. coderanger: is there anything blocking acceptance of this patch?

I am using Trac trunk (0.12dev) and have a similar problem : the redirect is not necessarily to the start page but if you were in an "edit" page (wiki edit, ticket modification) and when submitting your changes a perm redirect occurs, the modification is lost and you have to reapply it. If you think this is not the same problem, I'll open a new ticket.

The fact that your permission has expired is definitely a different problem. I'm somewhat in agreement with coderanger it doesn't make much sense; the only thing I could think of would be if your permission token expired due to time. Hitting refresh before editing might help? I've let tickets sit for a while without doing anything and then edited without a problem but this might be very dependent on what authentication scheme you are using.

Because ticket modification data is POSTed whereas this is just doing redirects (GET) that don't carry the post data along with it, this plugin (with or without the proposed patch here) will *not* solve the lost data problem.

Event Order

1. Trac has a permission error
   • PermRedirectPlugin without the above patch, no referrer info is passed (in our setup at least). This is confirmed through firebug and apache logs.
   • With the patch, when we do the redirect we add a QueryString? parameter named "referer" with the value of the page that was requested.
   • Trac w/o the plugin renders an error page, that when you click the link to go to login, the Http Header "referer" is added because you followed a standard link.
2. Login url does what it is supposed to (http basic auth over ssl in my setup).
3. When you get to the login page under recent Tracs(slightly after .11 was released there was a fixup patch so that it would read referer from all params not just the headers) it redirects you to whatever location is given in the "referer" request parameter.

In any of the above scenarios under point 1, POST data is lost. From what I know of HTTP redirects there isn't a good way to thread the POST data. A couple not good options: keeping it in the server's session memory, sticking it in a cookie, trying to create querystring parameters out of everything posted.

I applied UnwashedMeme's PermRedirect?-urlfix.2.diff patch, works great against Trac 0.11.2.

Is there any chance of getting this patch applied?

We have been using it successfully for months, it sounds like others have had success as well, and it just worked again on an entirely fresh install.

Thanks,

Russ

How is this plugin and this patch supposed to work? (It seem it doesn't work with me)

With this plugin the url of the login page has become something like this:
https://my.trac.example.com/login?referer=http%253A%252F%252Fmy.trac.example.com%252Froadmap

But the inner workings of the /login page seems not to react on any of this ?referer= parameter.

Has anybody been getting this to work?
Thanks,
Dirk

Dirk,

It's been working fine for us for quite a while-- really wish we could get this patch applied to the plugin.

You need to apply the patch PermRedirect-urlfix.2.diff to the plugin before installing it with python easy_install-- looks like you might already have that point. The login url you gave looks correct; that's mostly what this plugin+patch provides.

Beyond that we rely on handling introduced in trac in [T7493] (comment:6)-- that was sometime during early trac 0.11. The login page at this point is supposed to, on successful login, redirect you back to the page specified by the referer.

Are you using a recent-ish trac (0.11+) with this plugin and patch applied? What happens after you login do you land on default page, are you still on the login page? Do you have any other plugins that are trying to intercept/munge the login procedure?

I'm running Trac 11.4. And I have the Account Manager plugin enabled. Could this be interfering with the login in an unwanted way?

Thanks, Dirk

Replying to labs@ixopusada.com:

I'm running Trac 11.4. And I have the Account Manager plugin enabled. Could this be interfering with the login in an unwanted way?

Yeah, I've heard reports of that plugin interfering especially if you have it configured for forms auth. I don't see a reason why the forms auth shouldn't be able to work with this, just reports that it doesn't. That will be a bug report over there, that it is ignoring the referer variable added in [T7493].

Getting back at this problem. I posted the presumed bug at the AccountManager ticket about this #3783, but nobody there responded. Now getting fed up with this and so I'm looking to solve it myself. :-)
After some digging, it seems that the ?referer= parameter is being received by the plugin. It's just tripping over the url quotes. Also the code in [T7493] doesn't seem to unquote the referer parameter.

Is that correct? Where is the unquoting suppose to happen? The referer is now http%3A%2F%2Fmy.trac.example.com%2Froadmap (as seen inside the _redirect_back method)

Thanks,
Dirk

Confirming the upgrade to trac 0.12 went fine. Plugin with patch attachment:PermRedirect-urlfix.2.diff still works great for us.

any chance of getting it applied coderanger?

Ok. I finally fixed my issues (involving http <-> https and the AccountManagerPlugin).
The how to and the patch can be found here: #3783

AccountManagerPlugin accepts the referer argument now, but PermRedirectPlugin still doesn't generate the argument.

Any chance this will get fixed?