Modify

Opened 6 years ago

Closed 4 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: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: normal Keywords: login form based html
Cc: sascha_silbe, rblank 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)

acct_mgr_https_referer_fix.diff (1.4 KB) - added by labs@… 4 years ago.
Patch to fix redirecting the the original referer via https detour

Download all attachments as: .zip

Change History (16)

comment:1 Changed 6 years ago by mgood

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.

comment:2 Changed 6 years ago by arnuschky

Thanks for the fast answer, I will contact the author of the noanonymous plugin and ask for a fix.

comment:4 Changed 6 years ago by mgood

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: Changed 5 years ago by labs@…

  • 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 4 years ago by labs@…

Patch to fix redirecting the the original referer via https detour

comment:6 in reply to: ↑ 5 Changed 4 years ago by labs@…

Replying to myself:

To reiterate my setup and my needs:
My setup is the following:

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:

  1. http:trac.example.com and https:trac.example.com are being seen as two different base_urls (so redirecting is refused)
  2. 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:

  1. Download the source code of AccountManagerPlugin
  2. Find the code to patch/fix
  3. Build the plugin as a new .egg (with python setup.py bdist_egg)
  4. Transfer the .egg to the (staging) server
  5. Rename and overwrite the new .egg onto the old .egg file
  6. Restart apache
  1. 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 4 years ago by arne.brutschy@…

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 4 years ago by labs@…

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

  • Keywords needinfo added
  • Owner changed from mgood to hasienda
  • Summary changed from form based login method does not forward to main url if request not known to [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 4 years ago by hasienda

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 4 years ago by vasili `at' techcollective.com

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

  • Cc rblank added
  • Keywords needinfo removed
  • Status changed from new to assigned
  • Summary changed from [patch] Form based login method doesn't forward to main URL on unknown request to [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 4 years ago by vasili `at' techcollective.com

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 in reply to: ↑ 12 Changed 4 years ago by hasienda

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

  • Resolution set to fixed
  • Status changed from assigned to 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.

Add Comment

Modify Ticket

Action
as closed The owner will remain hasienda.
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.