Ticket #10642 (closed enhancement: fixed)

Opened 6 months ago

Reported by: Assigned to: ejucovy ejucovy normal PermRedirectPlugin normal

Description

It's often important to ensure that login occurs over HTTPS instead of HTTP, while the rest of the Trac site can remain served over HTTP. Currently the only way to do this is with rewrite rules in the front-end web server, as described in trac:ticket:4733

A solution within Trac was proposed on that ticket, relying on a new trac_login_uri setting to generate https links to login. However, that solution would not prevent users from manually visiting the http:// login URL without following a link, and would also require that any plugins which generate login links (including PermRedirectPlugin) be updated to use the new method.

A more secure-by-default approach would be to use a request filter that intercepts requests to the login page and redirects them to the HTTPS version of the same page. Of course this would not prevent users from manually POSTing credentials to the login page over HTTP, but (a) this would have to be a deliberate choice because the login form itself would only ever be served over HTTPS, and (b) in scenarios where authentication occurs within the Trac environment (e.g. AccountManager login as opposed to Apache authentication) the POST request itself would also be intercepted, so the response would not leak any information about whether the credentials were valid.

Since this is conceptually similar to how PermRedirectPlugin handles its current feature-set, I think it makes sense to add this feature to PermRedirectPlugin as well.

Change History

11/20/12 14:43:16 changed by ejucovy

• status changed from new to closed.
• resolution set to fixed.

I've implemented this in [12374].

It adds a new option to control the behavior. By default it is false. To enable the feature, you would activate the permredirect component and then set

[permredirect]


No new components are involved; the same permredirect.filter component is used for both this feature and the plugin's original/core feature. Therefore, in [12375] I also added a new option to disable the plugin's core feature -- otherwise it would be impossible to use the HTTPS-only feature without also using the redirect-to-login-page feature. (Having two separate components for these features seems overly complex.)

To disable the plugin's core feature you would set

[permredirect]