HTTP Basic auth headers not supported by Apache FastCGI

Thanks, I found the following problems:

+++ b/restws_basic_auth/restws_basic_auth.module
@@ -11,6 +11,17 @@
+  // Try to fill PHP_AUTH_USER &  PHP_AUTH_PW with REDIRECT_HTTP_AUTHORIZATION

Two spaces after &

+++ b/restws_basic_auth/restws_basic_auth.module
@@ -11,6 +11,17 @@
+  if (isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])
+    && !empty($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])

The isset is unnecessary when !empty() is used.

So, I fixed those, improved comments and code formatting a bit and added some docs to the README.

+++ b/restws_basic_auth/README.txt
@@ -15,3 +15,14 @@ You can configure the regex (suitable for preg_match()) in your settings.php,
+  RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Fixed miss newline at end of file.

grml, new line should not have indentation.

Not sure about this, looks like an Apache specific problem? This was never a problem for Nginx and FastCGI/FPM, so what web server are you using? Why can't Apache pass in the correct headers? Why can't FastCGI just pass on the headers to PHP?

Yes, it's apache with php as fast-cgi.

see https://bugs.php.net/bug.php?id=35752 and http://stackoverflow.com/questions/3663520/php-auth-user-not-set

It seems to be an apache only problem. Looks like one can configure at least mod-fast cgi to pass through unknown headers, but that's not the case in our server configuration (which we have no access to). In our case authentication details are by default not available in $_SERVER at all - what sucks. But the .htaccess work-a-round does it.

So I'd suggest adding it but fixing the docs to make clear it's an apache problem? -> Updated patch with updated docs.

+++ b/restws_basic_auth/restws_basic_auth.module
@@ -11,6 +11,14 @@
+  // Try to fill PHP_AUTH_USER & PHP_AUTH_PW with REDIRECT_HTTP_AUTHORIZATION
+  // for compatibility with PHP FastCGI.
+  // This requires the following line in your ".htaccess"-File:
+  // RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

The comment should also mention that this is Apache-specific.

Needless to say that we don't have to hack around like this in Drupal 8, Symfony would handle this case for us :)

Otherwise looks good!

Needless to say that we don't have to hack around like this in Drupal 8, Symfony would handle this case for us :)

:-)

Updated patch accordingly.

OK, I guess you can commit that yourself :-)

Thanks! Yep, committed and pushed to 2.x and 1.x.

klausi pointed out 7.x-1.x should only receive security fixes, so reverted it for 7.x-1.x