Opened 16 years ago
Closed 14 years ago
#3783 closed defect (fixed)
[patch] Form based login method doesn't forward to default Trac URL on referrer outside of Trac
Reported by: | arnuschky | Owned by: | Steffen Hoffmann |
---|---|---|---|
Priority: | normal | Component: | AccountManagerPlugin |
Severity: | normal | Keywords: | login form based html |
Cc: | Sascha Silbe, Remy Blank | Trac Release: | 0.11 |
Description
The form based login does not forward to the main page correctly upon a successful login. This happens when the original request is not known.
In my special case, the original request is never known, as I redirect unencrypted requests to the login form to a encrypted connection. On the way, the original request gets lost.
Result: The user ends up on the login screen again, even after the login was successful. Additionally, no message indicates that the login was successful.
Trac-0.11.1 and TracAccountManager-0.2.1dev_r3857-py2.4
Attachments (1)
Change History (16)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Thanks for the fast answer, I will contact the author of the noanonymous plugin and ask for a fix.
comment:3 Changed 16 years ago by
I tried the following:
https://localhost/projects/test/trac/login?referer=report https://localhost/projects/test/trac/login?referer=projects/test/trac/report https://localhost/projects/test/trac/login?referer=https://localhost/projects/test/trac/report
But all of these do not work. The plugin always redirected me to the wiki.
comment:4 Changed 16 years ago by
The value should be an absolute URL as in the last example. You may need to alter or add the base_url setting to trac.ini since the redirect logic here tries to verify that it does not redirect you to an external URL. If the URL does not start with the value in that setting it will be ignored and default to redirecting to the wiki.
comment:5 follow-up: 6 Changed 14 years ago by
Cc: | Sascha Silbe added; anonymous removed |
---|
Hi,
what's the current status of this bug?
I tried to install the PermRedirectPlugin with the AccountManagerPlugin, but indeed AccountManagerPlugin is not listening to ?referer=...
url parameters. According to the folks at PermRedirectPlugin's ticket tracker http://trac-hacks.org/ticket/2210[[br]]
it is ignoring the referer variable added in [T7493].
Dirk
Changed 14 years ago by
Attachment: | acct_mgr_https_referer_fix.diff added |
---|
Patch to fix redirecting the the original referer via https detour
comment:6 Changed 14 years ago by
Replying to myself:
To reiterate my setup and my needs:
My setup is the following:
- Trac 0.11.4
- apache + mod_rewrite to switch between http <-> https (for normal pages <-> for
/login
and/logout
) - PermRedirectPlugin
- AccountManagerPlugin
I need at least the /login
page to be over https, to secure the passwords being sent over the wire. But after login is successful I want to user to come back at the page where he/she was supposed to go (instead of being redirected to the home page).
I had two issues with this setup and my needs:
- http:trac.example.com and https:trac.example.com are being seen as two different base_urls (so redirecting is refused)
- Somewhere in the interplay between Trac itself, PermRedirectPlugin, AccountManagerPlugin and the mod_rewrite configuration, the referer parameter gets double url quoted. Like this:
https:// my.trac.example.com/login?referer=http%253A%252F%252Fmy.trac.example.com%252Froadmap
(%252F for a single '/')
The above attached patch fixes those two issues in the AccountManagerPlugin. I am not sure however, if this was the best location to fix those issues. There might be better patches (closer to the actual responsible bug ... which I don't where to file) possible, but this works for me :)
For reference:
- I'm using the apache + mod_rewrite configuration as described in
http :// trac.edgewall.org/ticket/4733
- PermRedirectPlugin ticket #2210 might be related (Thanks for the help Nathan!)
- Used a patch proprosed in this ticket
http :// trac.edgewall.org/ticket/3048
to fix the http <-> https mismatch.
Lastly, I had some problems with debugging and writing a fix for the AccountManagerPlugin, because the installed plugin .egg can't be upgraded that easy without breakage, see this issue http: // trac.edgewall.org/ticket/8779#comment:3
My workflow was the following:
- Download the source code of AccountManagerPlugin
- Find the code to patch/fix
- Build the plugin as a new .egg (with
python setup.py bdist_egg
) - Transfer the .egg to the (staging) server
- Rename and overwrite the new .egg onto the old .egg file
- Restart apache
- Use logging (
self.log.debug("blahblah")
)
Hope this is any useful anyone else with the same issues.
(And I hope that other readers can find the same persistence to struggle through the woods of trac- and trac-hacks-tickets and conflicting plugins. ...)
Best.
Dirk
comment:7 Changed 14 years ago by
Thanks for this update Dirk, as I have exactly the same issues (I am not using the PermRedirectPlugin, though). I'll test your patch as soon as I have the time and report back then.
BTW, what are the mod_rewrite rules you are using? These are mine (apache 2.2)
# rewrite all requests to trac login screens to use https RewriteCond %{REQUEST_URI} ^.*/projects/[a-zA-Z0-9\-_]*/trac/login.*$ RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [L,R] # rewrite all other requests to tracs NOT to use https RewriteCond %{REQUEST_URI} !^.*/projects/[a-zA-Z0-9\-_]*/trac/login.*$ RewriteCond %{REQUEST_URI} ^.*/projects/[a-zA-Z0-9\-_]*/trac.*$ RewriteCond %{SERVER_PORT} !^80$ RewriteRule ^(.*)$ http://%{HTTP_HOST}$1 [L,R]
A related problem I have is that the login screen gets loaded without css files and images, because the access to them is denied before login. How did you solve that?
comment:8 Changed 14 years ago by
My setup is quite different then yours, because I'm using a VirtualHost directive per project, instead of one VirtualHost for all projects. (Two VirtualHost directives actually, one for http and one for https)
And my htdocs directory is not under WSGI control, so this will just be served normally. Again, I'm following the directions described in this #T4733 ticket.
(Note: I had to use wrong slashes in the url http:
backslash, because this ticket's spam system won't let me post me otherwise. These must be http://forwardslash obviously. )
<VirtualHost 123.45.67.89:80> ServerName trac.projectname.server.tld # trac: rewrite to https:// when uri is trac login page RewriteEngine on RewriteRule ^/login https:\\trac.projectname.server.tld/login [R] Alias /chrome/common /var/trac/htdocs/common WSGIScriptAlias / /var/trac/wsgi/projectname.wsgi <Directory /var/trac/wsgi> WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all </Directory> <Directory /var/trac/htdocs> Order deny,allow Allow from all </Directory> </VirtualHost> <VirtualHost 123.45.67.89:443> # Listening on https for /login page ServerName trac.projectname.server.tld SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile "/usr/local/etc/apache22/ssl.crt/secure.crt" SSLCertificateKeyFile "/usr/local/etc/apache22/ssl.key/secure.key" # trac: redirect to non-https connection when uri is not login-uri # trac: go back to the http referer if there is one RewriteEngine on RewriteCond %{REQUEST_URI} !/login$ RewriteCond %{HTTP_REFERER} ^http:\\trac.projectname.server.tld/.* RewriteRule . %{HTTP_REFERER} [L] # trac: if there is no referrer, go to the original requested http uri RewriteCond %{REQUEST_URI} !/login$ RewriteRule ^/(.*)$ http:\\trac.projectname.server.tld/$1 [L] WSGIScriptAlias / /var/trac/wsgi/projectname.wsgi <Directory /var/trac/wsgi> WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all </Directory> </VirtualHost>
Hope this is any help.
Dirk
comment:9 Changed 14 years ago by
Keywords: | needinfo added |
---|---|
Owner: | changed from Matt Good to Steffen Hoffmann |
Summary: | form based login method does not forward to main url if request not known → [patch] Form based login method doesn't forward to main URL on unknown request |
I'd like to hear from someone with this or similar application, if/what further actions are suggested here.
comment:10 Changed 14 years ago by
Another ticket concerned to (in)proper redirection after (successful) login has been resolved by changeset [9263].
I wonder, if this ticket is resolved as well, or if ticket #7687 even has been a duplicate of this one. I didn't investigate into special, HTTPS related redirection cases, so there may be still something left to be done. Comments and new test results are welcome.
comment:11 Changed 14 years ago by
I ran into a problem today that is being caused by changeset [9263]. it happens if i browse directly to the login page from an unrelated website (e.g. starting from www.google.com, i go to my bookmarked login page at trac.instance.com/login).
I get an infinite redirect to /login after a successful login. i'm using trac 0.12.1 and AccountManager r9279 with no other plugins. If I reverse changeset 9263 the problem goes away.
comment:12 follow-up: 14 Changed 14 years ago by
Cc: | Remy Blank added |
---|---|
Keywords: | needinfo removed |
Status: | new → assigned |
Summary: | [patch] Form based login method doesn't forward to main URL on unknown request → [patch] Form based login method doesn't forward to default Trac URL on referrer outside of Trac |
I see, that you're testing with really recent version of both, Trac and AccountManagerPlugin, that's great. Thanks for reporting back, I'm all ears to you.
I guess, there is no referrer in the (bookmarked) URL leading you to the login. So could you please verify, that another URL
http://trac.instance.com/login?referer=http%3A%2F%2Ftrac.instance.com%2Fwiki%2FWikiStart
equal to urlencode(http://trac.instance.com/wiki/!WikiStart
)
would work just to rule out there is something else broken in your setup?
But as you pointed out, according to my test following your report, there is an issue, if you browse to the login page directly from outside of your Trac environment. Even if this is much less likely/common, it should be handled gracefully as well.
comment:13 Changed 14 years ago by
thanks for the quick reply. it works fine with the URL you supplied, so the problem is definitely caused by the lack of referer. maybe a redirect to '../' could be used as a default in this case? for us it's a common case, because we weren't using the PermRedirectPlugin and only allow access to logged in users.
right now i'm using trac 0.12, AccountManagerPlugin at r9279 with r9263 reverse-merged, and the PermRedirectPlugin and everything seems to be working fine.
comment:14 Changed 14 years ago by
Replying to myself:
![...] But as you pointed out, according to my test following your report, there is an issue, if you browse to the login page directly from outside of your Trac environment. Even if this is much less likely/common, it should be handled gracefully as well.
While working on other changes I (think that I) finally got a clue on this issue. The solution for exactly this situation is not only simple, but looks quite elegant to me. So it's bound to fix this issue once and forever, isn't it?
comment:15 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(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.
You need to change your redirect rule to go to "https://yourserver/login?referer=<whatever>" to override the fact that currently the referrer is going to be the unencrypted /login URL. Either point it to the index page, or if you want to get fancy there may be a way to write the redirect so that it uses the original referring page.