Jump to content

.htaccess hiding directory


dpiche

Recommended Posts

We just upgraded Apache (IHS actually) to IHS 6 (Apache 2.0).  The behaviour of an .htaccess file we have has changed.  Here is the situation.

 

TThe site has a .htaccess file requiring a username & password.  Then in a subdirectory there is a second .htaccess.  That one requires a different username & password to view its contents.

 

In the old version of Apache, you would see that subdirectory and when you click on it, you would be prompted for the login.  Now, the subdirectory is completely hidden.

 

What do I need to do so that the subdirectory's .htaccess doesn't hide the subdirectory and pop up the required login for the subdirectory?

 

Thanks,

 

Dan

Link to comment
Share on other sites

Can you post your old apache version (x.x.x) and new apache version (2.0.x)

 

Also can you post an excerpt from the two folders re: authentication

specifically any Satisfy clause, Authtype, Require ... (you can insert dummy user names/groups)

 

If possible, and if I have enough info I will try to simulate the failure on my machine.

 

But first...

 

If on Linux this may be due to underlying directory/file permissions I guess - which may have inadvertently changed.

It might be worth checking these if you have reinstalled the directory tree into a new disk or recreated user accounts - and that directory/file permissions aren't masking access by the apache user account which is running the server. Were you running as root previously?

Link to comment
Share on other sites

Hi,

 

Old apache version: IHS 1.3.26 = Apache 1.3.26

New apache version: IHS 6.1 = Apache 2.0.47

 

.htaccess file in the top level directory of the site:

--------

AuthName "Main site requires authentication"

AuthType Basic

AuthUserFile /home/mainuser/passdir/passfile

 

require user adminuser

--------

 

.htaccess file in child directory that is hidden

--------

AuthType Basic

AuthName "Password Required"

AuthUserFile /usr/apps/htaccess_subuser

 

require valid-user

--------

 

The directories are on an AIX (UNIX) box.  Permissions on the child directory include world read and execute.

If we delete the .htaccess file in the child directory it becomes visible through the site upon refreshing the browser.

 

Each AuthUserFile has only one user in it.  The user is different in both files and they aren't system users.

 

Thanks,

 

Dan

 

 

Link to comment
Share on other sites

I avoid .htaccess files like the plague personally and do everything in the main server config. Their behaviour is susceptible to confguration options set in the main config file. Of course this isn't an option if you don't have control of this file.

 

I suspect that if the main server config and .htaccess remain unchanged as well as file permissions then the *default* behaviour of some inherited restrictions has changed from 1.3.x to 2.0.x but can't recall reading about this and as I don't use them I can only suggest some broad options.

 

I'd be tempted to check out this theory by temporarily replacing password access with simple deny restrictions to see exactly how the top level site inherits downwards then check to see if this matches what you have in the combined server config + .htaccess files.

 

I'd also check the AllowOverride statement in the main server config file to see whether you've used AllowOverride ALL or set flags which might inadvertently have triggered the problem. Did the main server config change during the upgrade?

http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride

 

Perhaps check AllowOverride with Authconfig, Limit and Options if ALL isn't used.

 

You have probably already read this http://httpd.apache.org/docs/2.0/howto/htaccess.html and noted how directives are inherited.

 

Might also be worth scanning through your "allow from" and "deny from" heirarchy

 

Unfortunately I use Windows so any simulation I did wouldn't really throw much light on things.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.