We use mod_rewrite (non-relevant config removed):
<VirtualHost *:80>
<Directory /var/www/admin>
RewriteEngine On
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>
</VirtualHost>
<VirtualHost _default_:443>
AddExternalAuth pwauth /usr/sbin/pwauth
SetExternalAuthMethod pwauth pipe
<Directory /var/www/admin/>
AuthBasicProvider external
AuthExternal pwauth
AuthType Basic
AuthName "Admin"
AuthzUnixgroup on
Require group sudo
</Directory>
</VirtualHost>
- Y
On Thu, Sep 27, 2012 at 11:06 AM, Ben Johnson <b...@indietorrent.org> wrote:
> 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-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
