Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
This is just a note to say that it's worth testing this on a server where php runs in cgi mode. Securesite (which is very similar) has a weakness that it cannot work under php-cgi. So, I imagine the same is the case here. Once that is confirmed it would be helpful to document the fact for new users.
Comment | File | Size | Author |
---|---|---|---|
#12 | httpauth_cgi.patch | 967 bytes | decafdennis |
Comments
Comment #1
decafdennis CreditAttribution: decafdennis commentedHmm I wouldn't think the way PHP is installed would affect sending and receiving some headers.
But I'll look into the matter, thanks for your comment!
Comment #2
gregglesHere is the issue from securesite http://drupal.org/node/28408
Perhaps it will give some clues.
Comment #3
NaX CreditAttribution: NaX commentedTheir has been a workaround found for the CGI problem thanks to moshe weitzman. Have a look at the last few posts on this issue. http://drupal.org/node/28408
I am going to try to get the workaround into securesite later this week. The only complication is that it requires patching the .htaccess file.
Comment #4
decafdennis CreditAttribution: decafdennis commentedThanks, I'll take a look at it!
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedno patch to .htaccess. just add a few lines to settings.php. i am not running httpautgh on groupsbeta.drupal.org and soon groups.drupal.org. i had to tweak it a bit.
Comment #6
decafdennis CreditAttribution: decafdennis commentedI've just finished my virtualized Gentoo install, so I can test under CGI mode myself.
Comment #7
decafdennis CreditAttribution: decafdennis commented@moshe
How exactly, I can't get it to work with $_SERVER['Authentication'], I need the .htaccess fix.
Are you, or are you not?
Comment #8
decafdennis CreditAttribution: decafdennis commentedOops didn't close that last blockquote there.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedyou are probably right. the server admins at drupal.org likely made changed in their .conf file so that i didn't need to do anything in .htaccess
i am indeed using this on groups.drupal.org. i had to patch the init function so the auth would fire on specified paths (like seduresite). i only use this to protect rss feed paths. otherwise, users should login using regular html box. so i am not using the (neat) callback feature which typically fires on 403 error ... i use this module because securesite was getting too complex for my taste.
Comment #10
decafdennis CreditAttribution: decafdennis commentedThanks for your clarification. It pleases me you're using httpauth on groups.drupal.org, it always motivates to hear from people who're using your stuff.
Alright, I'll probably solve the .htaccess issue by asking the user if he/she wants to have the file changed automagically.
I submitted a feature request to httpauth that will allow authentication to be fired regardless of whether a 403 error was returned. This will be an optional feature.
Please: can somebody with the sufficient permissions close the blockquote tag after "a bit." in #8? Thanks.
Comment #11
decafdennis CreditAttribution: decafdennis commentedNote to self: fix this soon!
Will need porting to 5.x too.
Comment #12
decafdennis CreditAttribution: decafdennis commentedI applied the attached patch to all branches. You can either wait a few hours for the package update script to update the development package, or apply the patch yourself by running
patch < httpauth_cgi.patch
in the httpauth directory.You will also need to add the following line to the .htaccess file in your Drupal root directory, just under
RewriteBase /drupal
(might have a # in front of it) but above# Rewrite old-style URLs ...
:RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Works for me. Please tell me if it fixes everybody's problems, then I can find a user-friendly solution for the .htaccess fiddling.
Thanks.
Comment #13
karlrees CreditAttribution: karlrees commentedI still can't get this to work. I'm starting from a clean 5.1 install, and the only things I've done is enable the HTTP Authentication module and add the line from above to .htaccess. Is there something else I should be doing?
Comment #14
decafdennis CreditAttribution: decafdennis commentedAre you getting a username and password prompt?
Comment #15
karlrees CreditAttribution: karlrees commentedYes. It just repeats.
So, I've been doing a little debugging here and it appears that either the HTTP_AUTHENTICATION environment variable is not being set, or that PHP can't access it. Either way, I'm only able to access the HTTP:Authentication string if I put it on the query string. In other words, here is my .htaccess:
And here is my php test file (authenticate.php):
I figured this out from this page, by the way: http://www.besthostratings.com/articles/http-auth-php-cgi.html.
Comment #16
decafdennis CreditAttribution: decafdennis commentedThanks, I will try the same thing on my virtualized PHP-CGI-box, the environment variable should be set.
If the variable is not set, there is something larger at hand, maybe.
Comment #17
decafdennis CreditAttribution: decafdennis commentedCan you do the same test again, with the following alterations:
Add
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
to .htaccess just after deRewriteCond
but before theRewriteRule
Add
echo "<pre>"; var_dump($_GET); var_dump($_SERVER);
at then end of authenticate.php.Please send me the output, so I can see what variables are being set exactly.
Comment #18
karlrees CreditAttribution: karlrees commentedWell, I tried dumping the environment variables, and sure enough, .htaccess isn't having any effect on them. I did a little more digging, and apparently there is a server setting somewhere that prevents .htaccess from changing environment variables (see, e.g., comments to http://us.php.net/features.http-auth). I use HostGator. I guess I'll shoot them off an email to see if they can change their settings, or maybe even resort to hacking up a version that will authenticate using the _GET trick.
Anyway, here was the output:
Comment #19
decafdennis CreditAttribution: decafdennis commentedOK, I guess I'll change it so that it rewrites the HTTP:Authorization variable to the query string (
$_GET) instead of to an environment variable (<code>$_SERVER
). My only doubt is whether this poses a security threat... though I don't think the rewritten URL (including the query string containing as good as a plain password) is logged anywhere.karlrees, thank you, you're being very helpful!
Comment #20
decafdennis CreditAttribution: decafdennis commentedOK I changed some code. Please test it using the following in .htaccess:
Note that the development package may take up to 12 hours to be updated to the new code.
Comment #21
karlrees CreditAttribution: karlrees commentedSorry it took so long to find time to test it. It appears to work fine if I use the following code in .htaccess:
I'm not sure if this is the cleanest code, but this is the only way to make it so ?authenticate will work. Plus, it's more compatible if other stuff is put in the query string.
Comment #22
decafdennis CreditAttribution: decafdennis commentedGreat that we at least solved the problem!
Only the rewriting of the query string... Drupal does the following, which works if an existing query string is present:
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Actually the QSA is what should nicely append the existing query string. I'll run some tests.
Comment #23
karlrees CreditAttribution: karlrees commentedOkay, so I never really got this working the first time around. I had some bug where the query string would keep growing appending the last segment of the drupal path to itself (so, for example, if I tried going to admin/content?authenticate, I'd wind up at admin/content//content instead).
I'm sure there's a better workaround somewhere, and I'm not sure that my workaround won't cause problems for other people, but here's my eventual solution.
This is in .htaccess
I only changed two lines in the httpauth_redirect() function. I know, I should make a patch, but I'm lazy. Here's the relevant changes:
Hopefully this helps other people out there.
Comment #24
decafdennis CreditAttribution: decafdennis commentedI tested your .htaccess fix and it appears to work as advertised when using CGI or FastCGI.
It's now documented in the README.txt file. (I forgot to properly mention the issue# and your name in the commit message, sorry karlrees!)
The changes to httpauth_redirect() aren't necessary anymore, since I removed that function completely.
Thanks for all your help, everybody!
Comment #25
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.