Authentication on PHP/CGI installations

I think you missed a step. Under access control, you need to give roles the ability to login. If you don't do that, then no one can login.

I have exactly the same problem. I was wondering whether you figured out already what the problem was?

Well, a quick search on php.net give me the reason of my problem:

NOTE: The $PHP_AUTH_USER, $PHP_AUTH_PW, and $PHP_AUTH_TYPE global variables are available only when PHP is installed as a module. If you're using the CGI version of PHP, you're limited to .htaccess-based authentication or database-driven authentication using HTML forms to input the username and password and PHP to validate matches.

I have a CGI windows version... downloaded from php.net. I hope this solves this issue.

Using the securesite module on a webserver where PHP is not installed as CGI but as a module, solves this issue.

Read that manual excerpt. It can't be done. It's not me, simply the needed variables are not there.

I am also running a CGI php server but on Linux, and I really need this to work. So I hacked the code a little to use a webform.

I have never made a module before so I spent some time with the drupaldocs just to find out how this module works.

What I have done is added a setting that is Use Web Form, thinking about it now it should have been called Use HTML Form. If this is ticked it does not use the HTTP Authentication. As this is my first time working on a module I just need some to test it and check out if my coding is ok. The one thing that could need some work but I am not sure about how to do is the error message if some gets their login wrong or enters the wrong username and password.

I dont know how to create a patch yet so I attached a tar.gz. Hope its not a problem.

I am using your code and it appears to be working. I will be making some changes and will post if anyone is interested.

I have change things quite a bit from my first attempt. Like I said before I don't really know what I am doing, so this took me a long time. I have been using this code for a few weeks now. and it seems to work fine. I have not fully tested the email password feature but I tested it once and it seemed to work.

Things I have added or changed:

• Output of the form is a full html doc now, with a Head and body.
• Added a settings textarea for CSS theming of the form. I have some basic theming. The idea was to fit in with the drupal default theme
• Add a cron bypass so the cron can run.
• Logging of Failed login attempts and Logging of successful logins.

Some parts of this module still don't make sense to me and I think things could be better organized. IE. The login failed logging code that I have added is in 2 places. This to me is not good programming but I needed it to work and I was running out of time.

So of the text should be change. EG. Enter your username or your password. >> Enter your username and your password.

The login messages could also be improved

If you do make some changes please upload it so I can test your improvements.

First, this is a much needed addition, if for no other reason than to temporarily shut down a site for routine maintenace. Thanks to NaX's patch, it seems to be working for CGI-based PHP implementations. This requirement should really be in the module description. I'm still stepping through the logic of having duplicate code in the inc and the module itself, as well as adding some features along the way. Will post when it gets a little more polish.

Building on NaX's and other's work, here's the version I've done.

Settings
-------------
+ consolidated http-auth and html form setting to one variable
+ removed CSS, request error message variable settings
+ changed HTML Login and Password Reset form variable settings to represent message only (form logic embedded in functions, not settings)
+ added configurable HTTP-AUTH realm (Junyor - April 29, 2005 - 04:25)

HTML/Reset Forms
-------------
+ Reset Password form is not shown unless there is a Password Reset message variable
+ added inline error message
+ added simple dialog page template system

This likely breaks Drupal programming convention, but I think is still a step further than embedding CSS/page logic as a setting. Basically, there is a new file dialog.tpl.php which you put in one or more of your theme driectories, and skin as you wish to match your site. If this file is not found for the theme, then there is a very simple default dialog that will be used. This dialog (whether themed or the default) gets called by the function dialog_page, whose purpose is to display a small amount of text that bypasses the function theme_page. Examples might include trapping all error messages, loss of DB connectivity, or in this case, a login/password reset form. I would recommend moving dialog_page into theme.inc, but since I'm not yet running 4.7x, haven't seen how much has changed.

Authentication/Logging
-------------
+ removed duplicate failed log message for HTML form
+ added failed log message for http-auth
+ invalid login attempt logged only if username and password is provided
+ superuser (uid 1) automatically authenticates regardless of access settings

Misc
-------------
+ fixed password reset logic ($account was passing even with no matching record, likely same problem in user.module)
+ remove redundant code (empty functions: _securesite_user_pass, _securesite_settings, _securitesite_auth; duplicate functions: securesite_t; renamed functions: securesite_user_pass to securesite_user_auth)

Erhm... Looks like this branch (e.g. the html form) of securesite.module is deprecated with the 4.7x codebase. The dialog function I added above is also already in, called theme_maintenance_page. I did reuse some of the code to make that page themable as well, available here: http://drupal.org/node/50871

Great work. You cleaned up the code nicely. Better than I ever could.

There is one thing that I had a problem with for a long time, that I see your version also suffers form.

Browser Cache!

I found that in some browsers it would cache the logout page so the users would never really be logged out.

You can easily test it. (using clean url's)
Login >> domain.com/admin >> Logout >> change the url without refreshing the page to domain.com/admin or close the browser and reopen it and go directly to domain.com/admin

You should find your self on the admin logs page and if you refresh it you should see that there is no log for you logging out.

I found a way around this. It does not work perfectly but my users complain a lot less about this problem since I add the following.

Before any html output.

    header( "Expires: " . gmdate("D, d M Y H:i:s") . " GMT" );
    header( "Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT" );
    header( "Cache-Control: no-cache, must-revalidate" );
    header( "Pragma: no-cache" );

What you think. I think some browsers cache better than others. I have tested this with IE, Opera and Firefox and they had the same problem and they all showed improvements after adding the cache control. I don't think the HTTP-Auth way suffers from the same problem. What I did find a problem was clearing my uses cache after adding the cache control. The browser would continue showing the cached version of the login form for a long time. Eventually I posted requesting all users to hit F5 a few times the next time they were on the login form. That solved most the problems.

The reason this was such a big problem for me is that the site that I was using this on was a intranet and the login was for people that were out of the office and working on unsecured computers. Many users were working from shared computers.

I think you right. 4.7 makes this module useless. Its about time. Being able to lock down a site is very important. I have not fully test 4.7, but I think it only locks the site, I dont think it has has the same functionality as the securesite module. Maybe there is still live left in this module. I do think drupal core will not be complete before this type of functionality is included. Making drupal more suited to intranets and not just websites and blog's. When I get some time I will be testing 4.7 to see if an upgrade is possible without this module.

Thanks again Gestaltware.

Made some small changes to your version, take a look.

Form CSS
-------------
+ left align form buttons so IE does not break the layout of the dialog.
+ 0 margin and padding on form to remove the extra white space created in IE around the form.

Logging
-------------
+ moved module_invoke_all('exit') for logging of Anonymous users (on logout a user gets logged twice once as the user on the login page then after redirect as a Anonymous user on home page). Anonymous should be logged so to track possible hacking attempts and for logging of search engines by other modules.
+ set page title to login so page hit would be recognized as for the login dialog.

Misc
-------------
+ force redirect back to home after logout (to prevent caching of the home page, and to clear the url)
+ moved page exit's to more logical places (only when redirect and dialog output)
+ rename dialog.tpl.php to securesite-dialog.tpl.php, so not to be confused with any other module.

I ran into a problem this last week with the acidfree module. Video's were not playing. In my logs Anonymous User were getting hits for the login page. This lead me to believe that because media player did not an active session with the site it was not able to play the video.

So I have added a page filter to the settings page. I used the code from the block display settings page. By adding (filemanager/active*) to be filtered, media player was able to play the video's. You have to give Anonymous User access content permissions for it to work else the user will get a access denied error. I did not like the idea of giving such permission to the anonymous user role, so for security reason I add a IP session check function. If selected this will check to see if an active session exists for that uses IP address before bypassing.

Change log updates:

Settings form
-------------
+ grouped similar settings in field sets.

Bypass Login Filter Pages
-------------
+ added the ability to bypass certain pages.
+ added a IP session check. If enabled the bypass will only take place if a users has an active session with their current IP address. Used with embedded video using the Acidfree module.

I think this is ready to be add to CVS for 4.6.

While looking into upgrading to 4.7 I found some bugs with HTTP_AUTH when logging out. This is fixed and along with some small changes.

..and here is the 4.7 version. Tested on RC1.

Some unnecessary code I add blocks the bypass filter pages in certain circumstances. Here is 4.6 fixed.

And here is 4.7 version fixed.

Hi all,

Would the patch mentioned above work with a module-based PHP environment? We are currently working on how to secure our site thus tried securesite but it came out with the very same problems you encountered.

Thanks

I'm trying to install this patched module and am having trouble getting it configured correctly. Running Drupal 4.6, PHP as CGI.

When I upload the files to modules/securesite and activate the module, I am automatically prompted to authenticate via HTTP-AUTH and I get locked out of my site. I can change the 'status' value from 1 to 2 in mySQL so that I can try to configure the module, but admin/settings/securesite is black except for the submit buttons. Also, I have to paste that path in the url window, there are no links anywhere else to get to that page. Where are the other settings for this module actually stored?

I've run out of things to try. This would be a very handy module but I'm afraid I may have to give up on it. Anyone have any suggestions?

Lawrence

I should add that I am trying to install this module in CivicSpace 4.5.

I have just tested my patch with a fresh install of drupal 4.6.8 and it worked just fine.

The settings page comes up fine and the default is to have securesite auth disabled. Make sure you have the correct and latest version of the patch.

I tested it using attachment on follow-up post 21 [http://drupal.org/node/28408#comment-87339].

If you using a 4.7 module with 4.6 you should have problems with any page that has a form because of the forms-api changes in 4.7.

I don't know about CivicSpace. Because it was based on drupal it might work.

i have only taken the module as of 4.7.

If someone could post a patch against the 4.7 release, and not an entirely new tarball, so that i can check out the changes.
Also, i am only set up to test with php as a module (i have never, in my entire life, run php as cgi).

i will not be committing any changes to the 4.6 release.

I am not very good at creating a patch. I have only done it a few times, but I gave it a try. Hope it works and helps.

This patch is sort of a rewrite of the secure site module so the patch pretty much replaces everything, I don't know how useful that will be to you. The patch excludes the dialog.tpl.php file for some reason. I don't know how to include it in the patch. But you can get it from the above tarball.

I hope you find this patch useful. I have been using it on a site since the first version of the patch back in November 5, 2005. This patch has evolved a lot since then and the April 6, 2006 version has not given me any problems and now does every thing I need it to do.

For some reason the patch was not attached to the post so I will try again, here...

I think the preview messed it up or maybe drupal.org was being updated.
And this issue lost all its details. Sorry.

NaX, there seem to have been some changes to the code since your last 4.7 patch. If you will make a patch for the current version, I'll look at it.

I initially committed the 4.6 patch, but had to reverse it because it prevented other critical patches from being applied. I will revisit this if someone will make modifications based on the original code.

I download the latest version of both 4.6 and 4.7 and created a patch for both for you to try. One small update to the 4.7 version. I add a description to the radio buttons that was in the 4.6 version, but missing from the 4.7 version. As mentioned before the dialog.tpl.php is not in the patch. It is not need to use the module as it is only used if placed in the default theme dir with the filename securesite-dialog.tpl.php. You can get the dialog.tpl.php from the last tar ball, or if you want I can post it as an attached file.

Here is the 4.6 version.

Here is the 4.7 version

I need to make sure we don't lose previous updates by applying these patches. They will be easier to evaluate if they follow the Drupal coding standards.

Since this is a substantial modification, it may be best to wait until the remaining securesite patches have been committed before making a patch based on the current version.

All other patches have been committed. I am now ready to accept a patch for this issue based on a rewrite of the latest version in CVS, as long as it follow Drupal coding standards.

Here is a patch on the CVS version. I hope I got it 100% standard compliant.

The code looks good, but I'm still finding it difficult to compare the differences. Is there any particular reason that functions are in different files and in a different order from the current version? This will make future revisions more difficult.

I tested the patch and I was able to download and patch the latest CVS using patch -p0 < securesite_cvs_nax.patch no problem.

Yes, functions have been moved around and reordered. The .inc file now only contains functions that return HTML. All the module logic is in the .module. You must remember this is a rewrite of the secure site module. Reorganizing the module was required as we were adding a authentication method. I think some functions have been removed completely and their is also now one less function in the .module file.

I intend to add a lot more comments to make it easier for people to follow.

What would you like me to do?
Have you tested these changes?

I'll accept the patch as is.

Committed to DRUPAL-4-7 and HEAD.

this issue seems to have veered away from HTTP Auth + CGI. Lets bring it back there, and reopen it. drupal.org is moving its sites to fastcgi and groups+securesite had to be patched in order to keep http auth functional. It turns out that you *can* read credentials from fastcgi. See http://www.besthostratings.com/articles/http-auth-php-cgi.html

See attached. I hope someone can turn this into a real patch. The module has changed a lot and now i can't figure out where this check belongs. It should probably be wrapped in an if() which checks for the presence of $_SERVER['Authorization'].

Actually, my patch works fine if just pasted into settings.php. So one could just document the need for this in the README and be done with it.

Ok your patch seemed to work once I patch my .htaccess with

RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Still got some more testing to do, then I will see about getting this into CVS.
Nicely done moshe weitzman, this will solve a lot of problems for some people including myself.

Sorry for the delay on this.

I have created a patch. It patches the .htaccess and the securesite.module file. If you have PHP installed as CGI please test it.

Now the question is how to use this patch. Do we release the patch as part of the module and if people need it they should patch their installation. Or commit the changes to the securesite.module file and release a patch for .htaccess. Or do we try to convince the durpal core that patching the .htaccess that gets distributed with core is a good idea.

If we distribute a modification for .htaccess I would recommend including a complete file rather than a patch. Patching is too confusing for new users.

I agree with that. Even experienced windows users struggle with patching.

Patch solves the problem running PHP as CGI for me. I have Site5 hosting and before, I could *not* get HTTP Auth to work.

With this patch, it works great :-D

And I vote for including a fresh, clean copy of .htaccess for users to overwrite in their main directory *and* a patch file for the advanced users who will need it as well.

Hello,

please forgive the n00b question: would the patch work on a 5.1 installation?

TIA.

I copied the changes manually from the patch file and it appears to work well.

PS: Sorry for the issue title change, this comment form is quite confusing.

Actually, no, it didn't work, it seems I've got a little bit carried away.

The browser asks for the http-auth login and password, but the server never accepts it.

Not sure if the problem is with the script, the patch or my Dreamhost setup.

Adding this line:

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

to my .htaccess file (right below RewriteEngine on, as the first rule) makes me unable to log in normally. I didn't yet install the httpauth module, only patch .htaccess.

Login form submission simply fails without any error; I don't receive my cookie.

Should the rule go below the rest? Or does it need an extra condition?

I'm using the Drupal 5.1 release.

I have just re tested the patch with 5.1 and it worked just fine for me.
What I did was this.

Add this line to my .htaccess

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

Directly after this line

RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

And before this line

</IfModule>

Then replaced this in my securesite.module file

  elseif($securesite_enabled == 1 || $securesite_enabled == 2) {
    $edit = array('name'=> $_SERVER['PHP_AUTH_USER'], 'pass' => $_SERVER['PHP_AUTH_PW']);
  }

With this

  elseif($securesite_enabled == 1 || $securesite_enabled == 2) {
    // PHP CGI workaround
    if (isset($_SERVER['HTTP_AUTHORIZATION']) && !isset($_SERVER['PHP_AUTH_USER']) && !isset($_SERVER['PHP_AUTH_PW'])) {
      list ($auth_type, $auth_cred) = split (' ', $_SERVER['HTTP_AUTHORIZATION']);
      if ($auth_type == 'Basic') {
        list ($auth_user, $auth_pass) = explode (':', base64_decode($auth_cred));
        $_SERVER['PHP_AUTH_USER'] = $auth_user;
        $_SERVER['PHP_AUTH_PW'] = $auth_pass;
      }
    }

    $edit = array('name'=> $_SERVER['PHP_AUTH_USER'], 'pass' => $_SERVER['PHP_AUTH_PW']);
  }

Hope that helps.

Anyone to commit this??? I had to run this patch again, doh :)

The stumbling block is the .htaccess modification. It's not ready for release until it works with the standard Drupal installation. We should submit a patch for Drupal core if it has not already been done.

.htaccess and settings.php are two core files that are designed to be modified by the admin. just look at the comments in each ... core is not going to care about our directive, nor should it. my .02

The problem is going to be a steady stream of support requests and bogus bug reports from users who find the module doesn't work for them.

Would it be a big problem to release the module with the patch and give the user instructions on how to apply the patch if necessary?

That still wouldn't help users who have no shell access (or indeed file access to their Drupal codebase), but it would be better than realizing it doesn't work and searching the site to find this patch (or posting an endless stream of new issues that are all marked dupes of this).

Please review and comment on this documentation task
http://drupal.org/node/145658

What's the status here? The documentation issue is closed. The README.txt points to a specific comment in this issue, but the comment IDs seem to have changed, so it's not clear what solution is recommended.

It does seem like the comment IDs have changed.
The comments people should use are,

http://drupal.org/node/28408#comment-339159

http://drupal.org/node/28408#comment-339150

OK, I pointed the document to http://drupal.org/node/28408#comment-339150.

I think we should commit the code to the securesite.module and include a patch for .htaccess with instructions in README.txt. I don't like including whole core files in contrib modules since they need to be updated whenever a change is made to the core file. .htaccess especially can have security implications.

Objections?

I agree with you mostly. I think we should commit the code changes to securesite.module file and then document the 1 line that needs to be added to .htaccess. Because it is only 1 line of code that needs to be added to the .htaccess file I think new users will find it easier than patching a core file. Also if you make it a patch then we will need to maintain that patch for when changes to core take place, after a few releases its possible a patch created now will start failing. The documentation will just need to be clear on where to put the line of code.

My $0.02.

That works for me.

@NaX: The patch from #37 seems to have reverted the fix for issue #30492, meaning password resetting isn't working. I'd appreciate your feedback on a solution to that issue, possibly one where password URLs work. See http://drupal.org/node/204191 for details.

I don't like including whole core files in contrib modules since they need to be updated whenever a change is made to the core file. .htaccess especially can have security implications.

On one hand, the patch would also need re-rolling with every non-trivial change to core - but on the other hand, the patch warns you when it is out of date, while an outdated copy of the core file could silently cause security problems.

For me, the authorization is actually put into the REDIRECT_HTTP_AUTHORIZATION server variable, instead of HTTP_AUTHORIZATION. Here is what i did to remedy it:

  elseif ($securesite_enabled == 1 || $securesite_enabled == 2) {
    // PHP CGI workaround
    if(isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])){
      $_SERVER['HTTP_AUTHORIZATION'] = $_SERVER['REDIRECT_HTTP_AUTHORIZATION'];
    }
    if (isset($_SERVER['HTTP_AUTHORIZATION']) && !isset($_SERVER['PHP_AUTH_USER']) && !isset($_SERVER['PHP_AUTH_PW'])) {
      list ($auth_type, $auth_cred) = split (' ', $_SERVER['HTTP_AUTHORIZATION']);
      if ($auth_type == 'Basic') {
        list ($auth_user, $auth_pass) = explode (':', base64_decode($auth_cred));
        $_SERVER['PHP_AUTH_USER'] = $auth_user;
        $_SERVER['PHP_AUTH_PW'] = $auth_pass;
      }
    }

    $edit = array(
      'name' => (isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] : ''),
      'pass' => (isset($_SERVER['PHP_AUTH_PW']) ? $_SERVER['PHP_AUTH_PW'] : '')
    );
  }

I tested out the proposed solution at Dreamhost, which uses PHP as CGI, and it doesn't work. It seems like the HTTP_AUTHORIZATION variable is blocked somehow. The solution at http://labs.spaceshipnofuture.org/icky/HTTP%20authentication%20with%20PH..., which uses a GET parameter does work, though. Would anyone be opposed to a solution using that method instead of what has been previously proposed?

I am having a problem with applying the patch to 5.1. WHen I look at the 4.7 module it has the following lines I can replace:

  elseif($securesite_enabled == 1 || $securesite_enabled == 2) {
    $edit = array('name'=> $_SERVER['PHP_AUTH_USER'], 'pass' => $_SERVER['PHP_AUTH_PW']);
  }

But the 5.1 version of this module does not have those lines. So what do I have to replace to get this module working with a CGI based PHP? It seems some people have got it to work.

I am so confused. Anyone have any advice? I am running Drupal 5.7. Thanks!

Dan W

Have a look at comment 55 http://drupal.org/node/28408#comment-339159

I showed the steps I used to manually apply the patch to 5.1.

But things have changed a bit since then. The .htaccess stuff is the same, but the PHP has changed.

For Securesite 5.1.1

Change this

  elseif ($securesite_enabled == 1 || $securesite_enabled == 2) {
    $edit = array(
      'name' => (isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] : ''),
      'pass' => (isset($_SERVER['PHP_AUTH_PW']) ? $_SERVER['PHP_AUTH_PW'] : '')
    );
  }

To something like this

  elseif ($securesite_enabled == 1 || $securesite_enabled == 2) {
    // CGI Workaround
    if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
      list ($auth_type, $auth_cred) = split (' ', $_SERVER['HTTP_AUTHORIZATION']);
      if ($auth_type == 'Basic') {
        list ($auth_user, $auth_pass) = explode (':', base64_decode($auth_cred));
        $_SERVER['PHP_AUTH_USER'] = $auth_user;
        $_SERVER['PHP_AUTH_PW'] = $auth_pass;
      }
    }

    if (isset($_SERVER['PHP_AUTH_USER'])) {
      $edit['name'] = $_SERVER['PHP_AUTH_USER'];
    }

    if (isset($_SERVER['PHP_AUTH_PW'])) {
      $edit['pass'] = $_SERVER['PHP_AUTH_PW'];
    }
  }

And for 5.1.2

Change this

  elseif ($securesite_enabled == SECURESITE_AUTH || $securesite_enabled == SECURESITE_AUTH_ALT) {
    if (isset($_SERVER['PHP_AUTH_USER'])) {
      $edit['name'] = $_SERVER['PHP_AUTH_USER'];
    }

    if (isset($_SERVER['PHP_AUTH_PW'])) {
      $edit['pass'] = $_SERVER['PHP_AUTH_PW'];
    }
  }  

To this

  elseif ($securesite_enabled == SECURESITE_AUTH || $securesite_enabled == SECURESITE_AUTH_ALT) {
    // CGI Workaround
    if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
      list ($auth_type, $auth_cred) = split (' ', $_SERVER['HTTP_AUTHORIZATION']);
      if ($auth_type == 'Basic') {
        list ($auth_user, $auth_pass) = explode (':', base64_decode($auth_cred));
        $_SERVER['PHP_AUTH_USER'] = $auth_user;
        $_SERVER['PHP_AUTH_PW'] = $auth_pass;
      }
    }
  
    if (isset($_SERVER['PHP_AUTH_USER'])) {
      $edit['name'] = $_SERVER['PHP_AUTH_USER'];
    }

    if (isset($_SERVER['PHP_AUTH_PW'])) {
      $edit['pass'] = $_SERVER['PHP_AUTH_PW'];
    }
  }

Hope that helps.

I have just retested this patch by manually applying it. I also read back a bit to remind myself about what people had said about getting this patch committed.

I tested the .htaccess changes with and without securesite enabled on a normal php install I will have to look if I have any CGI installations available any more for more testing.
But even though I am not running CGI or fastcgi anymore the $_SERVER['HTTP_AUTHORIZATION'] was set and used correctly and unset when logged out after the AUTH dialog was displayed.

I think the best thing to do is to apply the PHP changes as per my last comment and document the one line you have to add to your .htaccess in the README.txt.

Something like:

Known Issues:

Authentication on PHP/CGI installations
  If you are using HTTP-AUTH and unable to login, it could be that PHP is
  running as a CGI binary. 

  Please add the following line at the end of your mod_rewrite rules in your .htaccess file.

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

  E.G.
  . . .
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
  
  RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
  
</IfModule>

  For more detail please see the following comments. 
  http://drupal.org/node/28408#comment-339147
  http://drupal.org/node/28408#comment-339150
  http://drupal.org/node/28408#comment-339159

Can anybody else think of a reason not to do it this way or maybe a better way?
It would be really nice to close this issue.

@Junyor
You have been doing a lot of the heavy lifting lately if you agree, feel free to commit this. (PS. Nice update to the Docs)

The attached patch implements NaX's suggestion. Committed to the DRUPAL-5 branch.

I seem to be getting this problem with the 6.x-2.x-dev version.

I had to make $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] available in _securesite_boot to be able to login.

I also wasn't able to logout as $_SESSION['securesite_login'] was always empty. I removed it for the time being though I'm not sure if this might break anything.

Authenticated users do have the access secured pages permission but anonymous users don't.

I also added the rewrite rule from above.

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