htaccess works in all directories except cgi-bin

htaccess frustrations....

[jmaggio]

Hi,

I am litle frustrated because my ISP (school choice, not mine) will not help out with this problem.

I have a simple htaccess file to password protect a subdirectory in cgi-bin. The script I am using keeps certain update functions in a subdirectory
(cgi-bin/calendar2/addevent/)

The script works fine. I have implemented this script on several servers with no problem. On this server, I place the htaccess file in cgi-bin, calendar2 or addevent and it does not work. Place the htaccess file in any other directory outside of the cgi-bin tree and it works perfect. This means I have coded the path to htpasswd correct and set up the htaccess parameters correct.

Any idea why it will not work in cgi-bin? One more point. When I started updating the site for someone there was no cgi-bin. I asked the ISP and they said there should be one and I created it myself. Permissions on cgi-bin and sub-directories are 755.

Thanks.

John Maggio

[jdMorgan]

jmaggio,

Welcome to WebmasterWorld!

I'm not sure what you mean by "...does not work" and "...I created one (cgi_bin)".

The resolution to this problem depends on how it does not work and how you created a cgi-bin file.

In many cases, hosting providers use a ScriptAlias directive to create cgi-bin outside the http-accessible filepath on the server. If this is done, then your .htaccess can't work in that directory because the actual directory is really located elsewhere in the file system and you are seeing the alias. Since your .htaccess is not really in the true server filepath used to reach cgi-bin, it won't be processed. See Apache mod_alias [httpd.apache.org].

I don't want to speculate any further without a better definition of the problem, but it may be that "your" cgi-bin and the "real" cgi-bin are in different places.

If I were in your shoes, I'd rename "your" cgi-bin to something else, and then tell the hosting provider, "No, the cgi-bin directory is still missing. Please fix it. Now."

Jim

[jmaggio]

Thanks for the response.

When I say htaccess does not work, I mean that no authentication window pops up when I run a script in the cgi-bin directory. If I place htaccess in any other directory, an authentication request will pop up and use my htpasswd file for the user verification.

I created the cgi-bin directory using MkDir in ws-ftp and set the directory as 755. I can run scripts and update databases in it. The only item not working as it should is htaccess.

I donot have shell access and a very limited support from the isp. Usually a week or so bewteen emails and no one is there who is familiar with unix when I call.

Here is my htaccess file:

AuthUserFile /common/webservice/o/oc/[e-mail]/WWW/cgi-bin/calendar2/addevent/.htpasswd
AuthGroupFile /dev/null
AuthName PleaseEnterPassword
AuthType Basic

require user ocmscalendar

I changed it dozens of times before luckyly trying it in the root directory(WWW) and it worked.

I tried setting up another directory to run the script in, but it would not work. The script came up as text.

[jdMorgan]

John,

If you are on a version of Apache lower that Apache 2.0, you might want to ask your host to check the order of modules in the LoadModule list of httpd.conf. Many times, people don't read the fine print, and the fact is that Apache pre-2.0 executes modules in the reverse order that they are loaded.

So, if your host added the module that processes your scripts to the *end* of the list, the scripts will be processed *before* mod_rewrite or mod_auth, and you will get no authenticaton dialog or .htaccess function for any request that the script_processing module handles.

Servers vary greatly in configuration, but the LoadModule order for the modules we're discussing here should be:

mod_perl (or php, etc.)
mod_auth
mod_rewrite

This is kind of unlikely as the cause of your problem, though, since you say the code works in other directories. However, one way or the other, it comes down to the host to fix it, since the "adjustments" that need to be made are in httpd.conf, and usually admin-only access, "out of reach" for the users.

If your script "comes up as text" then that problem is that the server doesn't have a handler defined for that filetype. You'll need to use Apache mod_MIME to set the correct handler. You can do this in .htaccess. An example would be:

AddHandler cgi-script .php .pl

This tells the server to pass PHP and PERL scripts to the cgi handler, instead of serving them to the client.

Others prefer to use AddType for PHP scripts:

AddType application/x-httpd-php .php

(I don't actually understand how that works, since it sets a MIME-type instead of forcing cgi processing, but it does apparently work -- proably because of some internal "hook" in Apache.)

If you get no satisfaction from your host, then it's time to change hosts. Life's too short and hosts too plentiful to deal with unsupportive hosts.

Jim