Hello,
Over the years, I've experimented with a number of mechanisms by which
to force SSL connections to a website, while at the same time:
a.) Preventing the "double-login" problem.
b.) Eliminating entirely the potential for users to log-in over a
plain-text connection.
c.) Redirecting plain-text requests (including their query strings) to
equivalent URLs over SSL, transparently, *even when Apache
authentication is required*. (This is to avoid sending "Access denied"
responses when SSL is required but the connection is plain-text.)
Is it even possible to meet all of these requirements simultaneously?
To address requirement a), I have done the following, traditionally:
<Location /securesite>
SSLOptions +StrictRequire
SSLRequireSSL
ErrorDocument 403 https://example.com/securesite
</Location>
This works well enough, and satisfies requirements a) and b), but if I'm
not mistaken, it precludes requirement c) from being met. Right?
Wouldn't a *plaintext* request to /some/arbitrary/path?foo=bar&foo2=bar2
force a redirection to the ErrorDocument location, while dropping
everything after /securesite? That is the observed behavior, and it
makes sense.
I tried appending %{REQUEST_URI} to the ErrorDocument location, but that
variable appears not to be available and is not expanded, so the request
is redirected to /securesite/%%7BREQUEST_URI%7D (doesn't work, needless
to say).
Could this be due to the following (from the Apache documentation at
http://httpd.apache.org/docs/2.2/custom-error.html#behavior ):
"At least REDIRECT_URL and REDIRECT_QUERY_STRING will be passed to the
new URL (assuming it's a cgi-script or a cgi-include). The other
variables will exist only if they existed prior to the error/problem.
None of these will be set if your ErrorDocument is an external redirect
(anything starting with a scheme name like http:, even if it refers to
the same host as the server)."
I realize that the last bit of this quote applies directly to this
situation, and is likely the reason for which using %{REQUEST_URI} does
not work in this context. But if I remove the https scheme from the
ErrorDocument directive, then this rule is no longer effective.
Does anyone have any thoughts as to how I can meet all three requirements?
Thanks for any help!
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|