Multirepository on https redirect to http

[otik@…]

I'm using Trac 0.9.5 on Debian etch, apache2, mod_python, ​https://SERVER/. I'm using multiple repositories. When I select repository trac link ​https://SERVER/project it redirect me to ​http://SERVER/project/. Then I have to rewrite ​http:// to ​https:// from this point it works well.

[otik@…]

You may try it ​trac@printflow

[lindig@…]

This is the same issue as #3207. I'd argue that tracd should have an optional config entry to hard-code the URL scheme to use to avoid the guessing done in web/api.py.

[otik@…]

• This may be good. But more setup, make harder to use, but if without it does work it is necessary

• sorry I'm not pythonist

• Why in repository list is link to /project instead of /project/ ?

[otik@…]

I was suppriced why addresses https://SERVER/project are rewrited to http://SERVER/project/ so

I hack this by adding to Apache:

  RedirectMatch ^/([^/]+)$ /$1/

I'm not sure what I done. I have just follow apache URL rewriting example. ​URL rewriting

I hope that somebody will add this to help or solve it in another (normal) way.

[Ilia Kantor]

Trac learns that its using https by checking HTTPS env.
Actually, it is set by mod_ssl, but AFTER trac already finished.
So it sets scheme to http and uses it to make urls.

The right fix would be to use "SetEnv HTTPS 1" in your CGI config or another setting of same kind in another config,
so trac will read it and be happy.

PS. bug exists at 0.10

[otik@…]

TNX this hepls (too).

May you add this instruction to help about how to configure apache2 to work with trac ? New user will be informed before problems...

[cboos]

See #2553.

[p.labushev@…]

RedirectMatch? magic makes things even worst - it gives you a false sense of protection instead of the real protection. How it works:

1. You start the trusted HTTPS session.
2. You click on some unprotected URL.
3. Your browser connects to the host over untrusted HTTP.
4. The host gives your browser untusted 302 Redirect because of RedirectMatch? on the server side.
5. Then your browser connects to the host over trusted HTTPS again and gets the final content over HTTPS.

There are possibility for MitM attack between 3 and 4. If an attacker would intercept your request over HTTP, he/she can reply to you with whatever content over the same untrusted HTTP session instead of the expected redirection. Then, if you didn't check the location bar to make sure there's https again and the URL is correct, you've been spoofed. Of course, the browser may give you a warning before you leave trusted HTTPS session, but the warning gives no extra safety if you still don't check the location bar later.

Besides, redirection magic and SetEnv stuff does not work for standalone Trac with HTTPS implemented on the frontend (like nginx).

So I think the real solution (with no unofficial scripts, patches and so on) would be to enforce ​https:// component for every generated URL and control that behavior per project from trac.ini.

[p.labushev@…]

Oh, forgot to add. The untrusted URLs appears in Timeline's entries, for example. With no regard to base_url settings. It's a standalone Trac 0.11.2 frontended by nginx with HTTPS.

[p.labushev@…]

Found use_base_url_for_redirect directive, works for me. Sorry for bothering. :)

[cboos]

No problem, I was about to suggest that ;-)

FTR:

---

Have you checked the [trac] use_base_url_for_redirect setting? (see TracIni#trac-section). Together with base_url set to https://..., I suppose this would do what you're trying to achieve.