I set the user name to "user" and the password to "password" to test it out. When the initial log in window shows up I enter the user name and password then the window pops up and gives me this . . .

A username and password are being requested by http://www.mysite.com. The site says: "Hello, user: User, pass: Password!"

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chriso’s picture

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

kalman.hosszu’s picture

Status: Active » Postponed (maintainer needs more info)

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

czigor’s picture

Category: support » bug
Status: Postponed (maintainer needs more info) » Active

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

czigor’s picture

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?

czigor’s picture

Enabling HTTP_AUTHORIZATION in safe_mode_allowed_env_vars does not help.

czigor’s picture

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.

Boobaa’s picture

Status: Active » Needs work
FileSize
595 bytes

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.

kalman.hosszu’s picture

Status: Needs work » Needs review

Thanks Boobaa!

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

Cheers

Boobaa’s picture

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.

Boobaa’s picture

FileSize
1.19 KB

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.

czigor’s picture

Status: Needs review » Reviewed & tested by the community

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.

kalman.hosszu’s picture

Status: Reviewed & tested by the community » Fixed

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

Cheers,
Kalman

Status: Fixed » Closed (fixed)

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

geek-merlin’s picture

Title: won't take user name and password » Won't take user name and password with FCGI
Version: 7.x-1.2 » 7.x-1.x-dev
Issue summary: View changes
Status: Closed (fixed) » Active

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.

geek-merlin’s picture

FileSize
1.34 KB

Patch flying in.

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

kalman.hosszu’s picture

Status: Active » Needs review
geek-merlin’s picture

This also works things out for Hetzner servers.

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

Flying RTBC

Daniel Wentsch’s picture

FileSize
1.07 KB

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.

ktch_my’s picture

Status: Reviewed & tested by the community » Needs review

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

joelpittet’s picture

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

Daniel Wentsch’s picture

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

Anybody’s picture

Status: Needs review » Reviewed & tested by the community

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!

eiriksm’s picture

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

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

Anybody’s picture

A new (+stable) release is really needed.

eiriksm’s picture

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

geek-merlin’s picture

  • axel.rutz committed 20dba6e on 7.x-1.x authored by eiriksm
    Issue #1829694 by Boobaa, axel.rutz, Daniel Wentsch, eiriksm: Won't take...
geek-merlin’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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