Opened 12 years ago
Closed 12 years ago
#10642 closed enhancement (fixed)
HTTPS login
Reported by: | ejucovy | Owned by: | ejucovy |
---|---|---|---|
Priority: | normal | Component: | PermRedirectPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: |
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.
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 thepermredirect
component and then setNo 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
The
redirect_login
andredirect_login_https
features are completely independent, so any combination of true/falses for the two options is possible and logically valid.