Shield doesn't work on fastcgi (and some other configurations)

Works fine for me and several others I work with. Short of the username or password simply being mistyped I dunno what to offer. This issue will remain for documentation, but I think we need some reproducible steps (feel free to reopen with some).

I was able to replicate this issue and determined that the $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] were not being set in my environment. Further research indicates that is a side-effect of using PHP FastCGI.

If your hosting environment uses FastCGI you will need to add the following to Drupal's .htaccess file (in the <IfModule mod_rewrite.c> section):

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization},last]

Adding rewrite rule to .htaccess is required but not good enough. Some servers may rewrite headers.
I needed to append these lines before HTTP authentication check to get shield working on my server.

//set http auth headers for apache+php-cgi work around
if (isset($_SERVER['HTTP_AUTHORIZATION']) && preg_match('/Basic\s+(.*)$/i', $_SERVER['HTTP_AUTHORIZATION'], $matches)) {
    list($name, $password) = explode(':', base64_decode($matches[1]));
    $_SERVER['PHP_AUTH_USER'] = strip_tags($name);
    $_SERVER['PHP_AUTH_PW'] = strip_tags($password);
}

//set http auth headers for apache+php-cgi work around if variable gets renamed by apache
if (isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION']) && preg_match('/Basic\s+(.*)$/i', $_SERVER['REDIRECT_HTTP_AUTHORIZATION'], $matches)) {
    list($name, $password) = explode(':', base64_decode($matches[1]));
    $_SERVER['PHP_AUTH_USER'] = strip_tags($name);
    $_SERVER['PHP_AUTH_PW'] = strip_tags($password);
}

Here attached a patch I created.

I tried both of these solutions and they didn't work for me, but I can confirm the bug is still there.

If I can help debugging, let me know how.

Minor update the to .htaccess mod_rewrite rule posted in #2. That rule worked for me, with the unfortunate side-effect of breaking form posts.

Removing "last" from the rule appears to resolve this:

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

pbull's fix in #5 worked for me without requiring the change from #3. Changing the title to more accurately reflect the situation.

I guess this should be added to the README.txt.

Here is the patch after confirm the location to place from greggles. Assume we will want to create a README or something to describe the use of the patch.

Just to be sure I tried this in a non-fastcgi environment and it does not seem to cause any trouble.

HTTPS

I'm using shield to tuck away my DEV and TEST subdomains in a FastCGI environment (Acquia DevCloud), and the patch in #5 initially does the trick.

However, I've now forced this domain to https by adding:

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]

Now, shield is bypassed. Any ideas?

@pragnatek - Did you put the change from #5 before or after the change you made in #9? Does the order make a difference?

@greggles - the order makes no difference.

BUT after a bit more digging my description was not correct.

What is happening is every https request is actually serving my live site my domain.com.
If i go https://dev.mydomain.com then I actually get my domain.com served although the browser address bar does say https://dev.mydomain.com.

So, the reason I'm not seeing Shield is simply that I only have it configured on dev.mydomain.com & test.mydomain.com but not on my domain.com.
If I remove my forced https rewriterule, I can get shield protected subdomains at, eg. http://dev.mydomain.com. But even then if I try https://dev.mydomain.com, I'm getting the site at mydomain.com (address bar https://dev.mydomain.com).

I need to check back with Acquia why this is happening. My SSL cert is not multi domain and only covers mydomain & www.mydomain, so maybe this is interfering.
Thanks.

Thanks for the patch. It made it work.

I think it's not an aplication problem.

@kalman.hosszu - can you expand on that? The patch and a README.txt for how to use it need to be committed if this module is going to work on fastcgi environments.

@greggles

The patch modifies the core's .htaccess file, and this module won't contains any core patch.

I modified the module's project page, and I added a link to this thread. I think it's enough, isn't it?

If you have any other question or request feel free to ask them!

Cheers

OK. It seems inconsistent to me to say that you won't ship a core patch but you will add docs to the project page.

In my experience, the .htaccess file is modified on most sites, so it is reasonable to expect people who install this module to be willing to change their .htaccess. A patch is the easiest way to describe what to do so it seems like you should ship it for convenience of fastcgi users.

If you disagree, then having documentation o the project seems like a decent alternate solution.

this is a bug of shield ? or Drupal core ? thanks !

Hi mcjambi,

I wouldn't call this an actual bug in the module or in core. It is just that some additional configuration that is required to have Shield work in a fastcgi environment.

The magic .htaccess line I could get things working is this:

RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L]

RewriteRule directive L means stop processing the rewrite rules for the request and is probably not what the various authors were meaning to do above!

I fixed this on FCGI by putting the following right after RewriteEngine On

RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule .* - [env=REMOTE_USER:%{HTTP:Authorization}]