Won't take user name and password with FCGI

Did you note the instruction on the Shield module project page about .htaccess on FastCGI? This bit:

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

The default text which reveals the username and password can be changed here: admin/config/system/shield

Hi,

please answer chriso's question because I don't understand what is your problem.

Is your problem that the username and password shows on the popup, or the popup shows after you added the correct password?

Cheers,
Kalman

I have the same problem: the popup shows up again even if I give the correct username and password. (Tested and confirmed by many coworkers. )

Both on localhost and the server I have FastCGI. On localhost the .htaccess RewriteRule solves the issue but on the server it does not: the $_SERVER['PHP_AUTH_USER'] etc. is not set in shield_boot().

Even the $_SERVER['HTTP_AUTHORIZATION'] is not set. (Btw, I am curious where $_SERVER['HTTP_AUTHORIZATION'] would be transformed into $_SERVER['PHP_AUTH_USER'] etc. )

Might safe_mode be a problem?

Enabling HTTP_AUTHORIZATION in safe_mode_allowed_env_vars does not help.

Without the shield module and following this:
http://mc-kenna.com/drupal/2012/04/simple-http-authentication-for-drupal...
does not help either. I must have a special server setting that stops this from working.

Okay guys, you are probably running something else than FastCGI--maybe plain old mod_cgi or something. In this case, two hacks are needed:

1. This line must be added to .htaccess right after the RewriteEngine on line (instead of the one mentioned on the project page):
RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L]

2. The attached shield.module patch.

Setting to NW because I don't (yet) know if this approach would work with FastCGI as well, somebody should test it. If it works, then the patch should be rerolled (to get rid of the old checks) and the project page should be updated, because it would mean my solution works the same with FastCGI and with plain old mod_cgi.

Thanks Boobaa!

Somebody should test it, and if it works well I will commit this fix.

Cheers

It looks like there are three cases, as described below.

if isset($_SERVER['GATEWAY_INTERFACE']) && $_SERVER['GATEWAY_INTERFACE'] == 'CGI/1.1':
  // We have CGI.
  if isset($_SERVER['FCGI_ROLE']):
    // We have FastCGI.
    $auth_var = 'REMOTE_USER';
  else:
    // We have plain old CGI.
    $auth_var = 'REDIRECT_REMOTE_USER';
  $auth_user, $auth_pass = explode(':', base64_decode(substr($_SERVER[$auth_var], 6)))
  if match($auth_user, $auth_pass):
    grant_access();
else:
  // We have mod_php.
  if match($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PASS']):
    grant_access();
deny_access();

Additionally, it turns out that different .htaccess lines are needed for FastCGI and plain old CGI:
FastCGI needs: RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Plain old CGI needs: RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
Either of these lines should be added to .htaccess right below the initial RewriteEngine on line in order to be effective, and it won't cause any problem in either case if both of them are included.

Updated patch is coming.

Well, $_SERVER['GATEWAY_INTERFACE'] is not a reliable source to determine if we're being run as (whatever kind of) CGI or mod_php, but php_sapi_name() seems to be so.

Here is the patch; I've tested it locally with plain old CGI and both .htaccess lines added (in the aforementioned order, but that shouldn't matter) and it works fine. Somebody with FastCGI should also give it a test before RTBC, though.

I can confirm that with this patch Shield works well with both old CGI and FastCGI.

The .htaccess modification that works for both cases is putting

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

right after the RewriteEngine on line.

Thanks, I committed the patch to 7.x-1.x branch. Boobaa I set you as the author of the commit.

Cheers,
Kalman

there is an issue with this: i'm at the *very* popular german uberspace provider and this patch breaks authentication:

we have

print php_sapi_name();

cgi-fcgi

and in $_SERVER:

[FCGI_ROLE] => RESPONDER
[REMOTE_USER] => NULL
[REDIRECT_REMOTE_USER] => NULL
[PHP_AUTH_USER] => my-username
[PHP_AUTH_PW] => my-password
[HTTP_AUTHORIZATION] => Basic d2VpbjprYXVm    

So the code expects encoded credentials in $_SERVER[REMOTE_USER] but there are none.
Looks like they are in the last 3 keys above.

Patch flying in.

Just changed the order of PW check so that should not harm anybody else.

This also works things out for Hetzner servers.

Flying RTBC

Thanks Axel.

I've just bumped into another problem: when running PHP with FCGI/FPM php_sapi_name() will return 'fcgi-fpm', so here's a small patch that includes that case.

Can anyone confirm the problem is fixed?
The issue is happening on one of the site in my dedicated server.
Both were installed 7.x-1.2, and one of the site is having the issue while another doesn't.
The patches and .htaccess lines doesn't solve the problem.
Manually dev module file replacement also can't solve the problem.

Linux
PHP 5.3.29
CGI/FastCGI

@SiaoKiax3 I RTBC'd #15 It fixed my issue apparently.

#19 looks like an interdiff so it would be applied on top of #15 but I'd have to ask @Daniel Wentsch to confirm.

Yes, that's right, my patch was applied on top of #15

I can confirm that patch 15+19 work great togehter and fix all the problems.

Please create a new dev and later on a new stable release. The new features are great. FPM and cgi environments are more and more common.

Thank your very much! RTBC!

Fixes my problem too (especially the part from #19)

A commit (and maybe even a release) would be nice? :)

A new (+stable) release is really needed.

Here is a convenient patch with both the patches in this issue. They are slightly unrelated, but at least it fixes the issue for 2 server setups that are not covered.

Being so blunt as to leave at RTBC since it just packages the patches nicer :)

.