Redirect trac http to https

[timlinux]

Since it is not possible to do many things in osgeo trac using ​http:// and many folks are invariably going to leave off the http's', it would be great if you could do a little redirection magic so that users visiting ​https://trac.osgeo.org/foo are automagically forwarded over to ​https://trac.osgeo.org/foo

Many thanks

Tim

[warmerdam]

Tim,

Are you suggest we redirect http: to https:? Your description above is confused, due to what I assume is a typo. I'm not actually aware of anything that we can't currently do via http for OSGeo trac instances. What are you referring to?

It has been suggested that we should move Trac to do all login's and authenticated actions via https, but I've not pushed this idea because for me https is deathly slow and painful.

[timlinux]

Ah geez I wrote a longer more informative reply but an accidental middle click in the comment box caused a page back and the reply was lost. Here is the precis version:

• I experience occasional permission denied trac messages when trying to edit trac tickets when logged in in http mode. Logging in under https always resolves the issue.
• I suggest to close this ticket and reopen when I can provide more factually based evidence (a screenie or something)
• regarding https, I'm on a very slow connection here (<= 5kbps) and dont notice any perceptible difference between http and https mode
• also regarding https, if I recall correctly, the same passwords are used for trac and svn, and it seems to me prudent that reasonable measures are taken to prevent passwords to a large body of source code (that lands up on many users desktops & servers) being sent around the internet in the clear.

Regards

Tim

[crschmidt]

Tim,

Trac uses somewhat aggressive cookie-based caching that is sometimes somewaht difficult to get around. Sometimes, even after logging in, you'll still get an old "Permission Denied". The reason that switching to HTTPS fixes this is not because of something inherent in HTTPS, but simply because it's a *different* URL: If you were to make everything HTTPS, you would (I expect) see the same behavior.

SSL requires additional round trips to the server: Frank is on a connection which is very high latency (which low bandwidth can cause, but generally doesn't directly) -- for Satellite, this latency is often in the .75s-1.5s range, which is a very different than the latency even on very slow connections. (Dialup is typically only in the 250ms range, for example.) So, there is definitely a possibility that Frank's connection would be a 'worst case scenario' for this.

I don't think that any of us are directly advocating for not making the login step HTTPS, simply ensuring that if you start at HTTP, login via HTTPS, you can still do your 'work' in HTTP: there is no particular security risk with this because trac doesn't use passwords directly other than for logging in. (It uses a cookie system to manage after that.)

Hopefully this helps address some of the concerns here. I think that the main fix at the moment would be to change the 'login' links to always be HTTPS, so that users are typically sent through that mechanism.

[Mateusz Łoskot]

I think this can be closed as fixed.

[strk]

I just noticed it isn't fixed. HTTP remains HTTP rather than being redirected.

[strk]

Sorry, I can't actually confirm the redirect isn't in place. I'll close this, please reopen if you find an HTTP link remaining as such (can't find it myself, although I don't see which configuration is doing this).