Opened 18 years ago
Closed 18 years ago
#3207 closed defect (duplicate)
tracd uses wrong URL scheme when behind https proxy
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 0.9.5 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I'm running tracd 0.95 (from Debian testing) on port 8080 and lighttpd serving https. Lighttpd is configured as a proxy for tracd - which works fine:
https://trac.vistabella.de/annot/
proxy.debug = 0 $HTTP["host"] =~ "(trac|svn).vistabella.de" { proxy.server = ("/" => (( "host" => "127.0.0.1", "port" => 8080))) }
However, I cannot login to become an authenticated user or do anyhting that provokes trac to issue a new URL:
My browser complains:
Safari can't open the page "http://trac.vistabella.de/annot" because it could not connect to the server "trac.vistabella.de".
This is correct, since it should connect using https. Is there a way to make trac aware of the fact that it is behind a https proxy?
After reading tickets here and the code in web/api.py, I suspect this could be related to #2553. Tracd is started with the following parameters:
tracd -d -p 8080 --auth *,/etc/trac/passwd,vistabella -e /pub/trac
Is there any parameter in the tracd.ini that affects the choice of the URL scheme tracd uses?
Attachments (0)
Change History (8)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
I'm quite sure (see below); this is also what the footer on https://trac.vistabella.de/annot/ says (the URL that I provided).
I took a look at the logfile that tracd produced when started without -d
. I don't know anything about HTTP proxying but at least from the logfile it seems that tracd has no way of knowing whether the original request was http or https (since it receices http and runs on port 8080 but must produce https). I therefore believe tracd must be told explicitly what scheme to use. Maybe the problem could be solved on the Lighttp side but I would prefer a tracd solution.
: ~; apt-cache show trac Package: trac Priority: optional Section: web Installed-Size: 1696 Maintainer: Jesus Climent <jesus.climent@hispalinux.es> Architecture: all Version: 0.9.5-1 Depends: python (>= 2.3), python (<< 2.4), python-clearsilver (>= 0.9.3), python-pysqlite2 | python-sqlite (>= 0.4.3) | python2.3-psycopg, python2.3-subversion, subversion (>= 1.0.1) Recommends: apache2 | httpd, python2.3-setuptools (>= 0.5a13) Suggests: enscript, python-docutils, libapache2-mod-python Filename: pool/main/t/trac/trac_0.9.5-1_all.deb Size: 300480 MD5sum: 5e8e4447aaae043d590589662f9ae1a1
comment:3 by , 18 years ago
To solve the problem, I have hard-coded the scheme to https
in web/api.py for now. So the URL provided no longer shows the bug.
comment:5 by , 18 years ago
I have similar problem but just in repository list (#3208), but can login without problem !. I'm not sure about same issue.
comment:7 by , 18 years ago
From my perspective, it's a design decision: Tracd running standalone does everything right. The problem is when running it behind a HTTPS proxy. We could argue, that it is the proxy's problem to fix the impedance mismatch between receiving HTTPS and proxying to a Tracd using HTTP.
On the other hand, I believe running Tracd behind a proxy is a very good choice and should be supported. Since (I believe) Tracd can't figure out the right URL scheme to use in all cases, a configuration option would be helpful . The heuristic implemented in source:trunk/trac/web/api.py seems not work in this case. Therefore I don't think #3207 is a genuine bug but a feature wish for better support of running Tracd behind a proxy.
Are you sure you're using 0.9.5 and not some earlier version?