Thanks for the module, I have always needed something like this and used .htaccess to do it. A module would be great.

Now, my problem is the following: I have installed Shield dev version on a Drupal 7 minimal and perhaps misunderstood something along the way, but the result was that the site was blocked. The username and password I introduced in the configuration did not work.

I could not get in. I had to delete the module by hand on the server. I tried Chromium and Rekonq and no difference, site blocked. I would love to provide more details and try this again, but there is no info in the logs of Drupal, and nothing noteworthy in the logs of the webserver.

Comments

boombatower’s picture

Status: Active » Closed (cannot reproduce)

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).

pbull’s picture

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]

achekulaev’s picture

FileSize
1.25 KB

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.

greggles’s picture

Category: support » bug
Status: Closed (cannot reproduce) » Needs work

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.

pbull’s picture

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}]

greggles’s picture

Title: Shield blocked site completely » Shield doesn't work on fastcgi (and some other configurations)

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.

boombatower’s picture

Status: Needs work » Needs review
FileSize
959 bytes

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.

boombatower’s picture

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

pragnatek’s picture

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?

greggles’s picture

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

pragnatek’s picture

@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.

rolturn’s picture

Thanks for the patch. It made it work.

kalman.hosszu’s picture

Status: Needs review » Closed (works as designed)

I think it's not an aplication problem.

greggles’s picture

Status: Closed (works as designed) » Needs review

@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.

kalman.hosszu’s picture

Status: Needs review » Closed (works as designed)

@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

greggles’s picture

Status: Closed (works as designed) » Fixed

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mcjambi’s picture

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

pbull’s picture

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.

Boobaa’s picture

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

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

Alan D.’s picture

Issue summary: View changes

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!

abhaisasidharan’s picture

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}]