httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <...@indietorrent.org>
Subject [users@httpd] Forcing SSL while redirecting with query string intact, preventing "double-login problem" and preventing plaintext authentication
Date Thu, 27 Sep 2012 15:06:40 GMT
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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message