httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yehuda Katz <>
Subject Re: [users@httpd] Forcing SSL while redirecting with query string intact, preventing "double-login problem" and preventing plaintext authentication
Date Thu, 27 Sep 2012 15:55:48 GMT
We use mod_rewrite (non-relevant config removed):

<VirtualHost *:80>
<Directory /var/www/admin>
        RewriteEngine On
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
<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

- Y

On Thu, Sep 27, 2012 at 11:06 AM, Ben Johnson <> 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
> </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
> ):
> "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:
> For additional commands, e-mail:

View raw message