Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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!"
Comment | File | Size | Author |
---|---|---|---|
#26 | won_t_take_user_name-1829694-26.patch | 1.08 KB | eiriksm |
#19 | shield-fcgi-fpm.patch | 1.07 KB | Daniel Wentsch |
#15 | shield-1829694-15.patch | 1.34 KB | geek-merlin |
Comments
Comment #1
chriso CreditAttribution: chriso commentedDid you note the instruction on the Shield module project page about .htaccess on FastCGI? This bit:
The default text which reveals the username and password can be changed here:
admin/config/system/shield
Comment #2
kalman.hosszu CreditAttribution: kalman.hosszu commentedHi,
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
Comment #3
czigor CreditAttribution: czigor commentedI 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().
Comment #4
czigor CreditAttribution: czigor commentedEven 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?
Comment #5
czigor CreditAttribution: czigor commentedEnabling HTTP_AUTHORIZATION in safe_mode_allowed_env_vars does not help.
Comment #6
czigor CreditAttribution: czigor commentedWithout 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.
Comment #7
BoobaaOkay 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 theRewriteEngine 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.
Comment #8
kalman.hosszu CreditAttribution: kalman.hosszu commentedThanks Boobaa!
Somebody should test it, and if it works well I will commit this fix.
Cheers
Comment #9
BoobaaIt looks like there are three cases, as described below.
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 initialRewriteEngine 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.
Comment #10
BoobaaWell,
$_SERVER['GATEWAY_INTERFACE']
is not a reliable source to determine if we're being run as (whatever kind of) CGI or mod_php, butphp_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.Comment #11
czigor CreditAttribution: czigor commentedI 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
right after the
RewriteEngine on
line.Comment #12
kalman.hosszu CreditAttribution: kalman.hosszu commentedThanks, I committed the patch to 7.x-1.x branch. Boobaa I set you as the author of the commit.
Cheers,
Kalman
Comment #14
geek-merlinthere is an issue with this: i'm at the *very* popular german uberspace provider and this patch breaks authentication:
we have
and in $_SERVER:
So the code expects encoded credentials in $_SERVER[REMOTE_USER] but there are none.
Looks like they are in the last 3 keys above.
Comment #15
geek-merlinPatch flying in.
Just changed the order of PW check so that should not harm anybody else.
Comment #16
kalman.hosszu CreditAttribution: kalman.hosszu commentedComment #17
geek-merlinThis also works things out for Hetzner servers.
Comment #18
joelpittetFlying RTBC
Comment #19
Daniel Wentsch CreditAttribution: Daniel Wentsch commentedThanks 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.
Comment #20
ktch_my CreditAttribution: ktch_my commentedCan 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
Comment #21
joelpittet@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.
Comment #22
Daniel Wentsch CreditAttribution: Daniel Wentsch commentedYes, that's right, my patch was applied on top of #15
Comment #23
AnybodyI 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!
Comment #24
eiriksmFixes my problem too (especially the part from #19)
A commit (and maybe even a release) would be nice? :)
Comment #25
AnybodyA new (+stable) release is really needed.
Comment #26
eiriksmHere 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 :)
Comment #27
geek-merlin.
Comment #29
geek-merlin