Inability to password protect directory on new Joomla Sites

[CobourgJohn]

The latest version of fresh installations of Joomla (e.g. 3.6) uses a different default .htaccess file. With it in place, any attempt to password protect a directory simply makes it totally inaccessible instead of requiring a password. My Joomla Sites with unprotected administrator directories get thousands of visits per month – a lot more than can be explained by my visits. they are probably hacker attempts.
With previous versions of Joomla, I have simply password protected “administrator” via CPanel. After much diagnostic work, I found that using an earlier version of .htaccess in the site root restored the expected functionality. That is, I first made sure my SEO settings were the same on the “source” and recipient sites and then simply copied the htaccess file across. Now functionality is correct - I am now able to password protect the administrator directory.
For anyone interested, the two diagnostic clues were that 1) the problem occurred on any directory, not just administrator and 2) the error message was a Joomla message even for a directory with no Joomla content.
Has anyone else seen this problem?

[Webdongle]

The latest version of fresh installations of Joomla (e.g. 3.6) uses a different default .htaccess file. With it in place, any attempt to password protect a directory simply makes it totally inaccessible instead of requiring a password. ...

Does that mean with
The txt.htaccess file renamed to .htaccess
.AND.
Using the Host's CP to password protect the /administrator folder
.THEN.
/administrator does not show the login box for the folder .OR. that you put in the folder user/pass and don't have access ?

... After much diagnostic work, I found that using an earlier version of .htaccess in the site root restored the expected functionality. That is, I first made sure my SEO settings were the same on the “source” and recipient sites and then simply copied the htaccess file across. ...

Did you test after you changed the SEO settings but before changing the .htaccess file ?
If not then it is entirely possible that by NOT uncommenting '#RewriteBase /' in the .htaccess that you renamed from .htaccess caused the problem.

... the two diagnostic clues were that 1) the problem occurred on any directory, not just administrator and 2) the error message was a Joomla message even for a directory with no Joomla content.
Has anyone else seen this problem?

.IF.
Rewrite was set to yes in Global config
.AND.
'#RewriteBase /' was not uncommented in .htaccess
.THEN.
It will be a Joomla 404 that you see ... either the Joomla/templates/system/error.php or the default Template's error.php

With your " ... much diagnostic work ... " did you test for that after you " ... made sure my SEO settings were the same on the “source” and recipient sites ... " but before you " ... and then simply copied the htaccess file across ... " ?

If you didn't then there is an easy way to test if your failure to edit the .htaccess correctly caused the problem.

[CobourgJohn]

Let me try again to describe the process.
I have not edited any htaccess files at any time. With older installations, I had no problem using CPanel to set password protection of the directory administrator. I have done that on several installations with no problem. With a recent installation of 3.6, I found that when I used CPanel to set a password requirement for administrator, it caused the directory to give a Joomla 404 error and no access and no request for a password. Using CPanel to remove the requirement for a password, restored access. I looked at an older installation and at the htaccess code and compared with the new one and noticed differences in the SEO portion. (This is the htaccess file that is in the site root alongside the index.php and configuration.php files.)
So I went into the new site and set the SEO settings to be the same as the older working site (set "add site name" to "after"). I tested that this change did not fix the problem. Then I uploaded the older htaccess file to the new site and now the password protection worked properly - that is, it asked for a password and accepted the password.
I don't know what it is about the htaccess file that is the problem, just that the new one causes a problem.
I have my work around but I thought the community or developers might be interested.

[Webdongle]

Let me try again to describe the process.
I have not edited any htaccess files at any time. ...

Then
Either you updated to 3.3.6 and have the same .htaccess as the pre updated site
or
You updated to 3.3.6 and have no .htaccess
or
It is a fresh install and you did not rename the txt.htaccess
or
It is a fresh install and you did rename the txt.htaccess but did not uncomment '#RewriteBase /'

In your first post you said that you copied the other .htaccess over so the last scenario is most likely the case. But in any of those scenarios you have not eliminated the possibility that not having a .htaccess which contains 'RewriteBase /' (or 'RewriteBase /subfolder' if in a subfolder) ... as being the cause.

... With older installations, I had no problem using CPanel to set password protection of the directory administrator. ...

Accuracy in definitions is vital. You still have no problem "... using CPanel to set password protection of the directory administrator ... " the problem occurs after setting it.

... I have done that on several installations with no problem. ...

Not all servers require '#RewriteBase /' to be uncommented but when in a subdirectory it needs to be uncommented and the subdirectory to be included in the path.

... With a recent installation of 3.6, I found that when I used CPanel to set a password requirement for administrator, it caused the directory to give a Joomla 404 error and no access and no request for a password. ...

That is indicative of Global config set to use Rewrite but not uncommenting '#RewriteBase /'

... I looked at an older installation and at the htaccess code and compared with the new one and noticed differences in the SEO portion. (This is the htaccess file that is in the site root alongside the index.php and configuration.php files.)...

The only difference between the txt.htaccess file of the 2.5.27 and 3.3.6 is spacin in the comments near the top

Code: Select all

# @package    Joomla
# @copyright  Copyright (C) 2005 - 2014 Open Source Matters. All rights reserved.
# @license    GNU General Public License version 2 or later; see LICENSE.txt

What code did you find different ?

...
So I went into the new site and set the SEO settings to be the same as the older working site (set "add site name" to "after"). I tested that this change did not fix the problem. ...

Of course that change would not have made any difference to your problem because that setting is for the value of the variable in the 'title' of the page when it is rendered and is only used after the page is found. Therefore a 404 error would mean that setting was not used.

... Then I uploaded the older htaccess file to the new site and now the password protection worked properly - that is, it asked for a password and accepted the password..../quote]Again that could be because the '#RewriteBase /' was uncommented in the other .htaccess

...
I don't know what it is about the htaccess file that is the problem, just that the new one causes a problem.
...

Then you do not know if failing to uncomment '#RewriteBase' was the cause.

... I have my work around but I thought the community or developers might be interested.

Please report it at http://issues.joomla.org/ if you still feel it is the current .htaccess causing the problem. And put a link to the report here please.

[leolam]

Do you have an .htaccess file in /public_html/administrator ?

Leo

[leolam]

I have been able to reproduce the issue and are investigating it

Leo

[Webdongle]

I have been able to reproduce the issue

Thank you Leo ... as you can confirm it I have set up an issue tracker http://issues.joomla.org/tracker/joomla-cms/4955


How have you been able to reproduce the issue ?

I have tried to reproduce but it appears to be working OK for me

Steps taken

1. Install a fresh copy of Joomla 3.3.6
2. Password protect /administrator

Result

• Pointed the browser at /administrator
• Entered user/pass
• FULL SUCCESS access admin without problems

Note:
The OP says he replaced the .htaccess and also says he did not edit .htaccess... But Joomla does not install .htaccess it installs htaccess.txt. 'One click installs' provided by Hosts typically install a .htaccess based on the Joomla htaccess.txt ... and those .htaccess's invariably do not uncomment '#RewriteBase /'.


Further testing:

• I renamed htaccess.txt to .htaccess
  FULL SUCCESS

Test were run on xampp

[leolam]

Thank you Leo ... as you can confirm it I have set up an issue tracker http://issues.joomla.org/tracker/joomla-cms/4955

How have you been able to reproduce the issue ?

Yes I have been able to reproduce and I have reached out to Nicholas of Akeeba (who is the htaccess Master) to provide guidance. Something between server settings and the Joomla htaccess file prevents this....

As soon as I have news I will post on the Tracker.... I will post my own experience on the Tracker anyhow so you will be able to see when and how it is happening in our case. jfyi: I also had my server team opening a ticket with Liquidweb (where we host all our 194 servers) and with cPanel to find the cause just in case someone is too busy too pick this up in Joomlasphere. Issue exists for sure

Leo

[nikosdion]

Is your host using Apache 2.4 by any chance? Password protecting directories on Apache 2.4 has changed.

[CobourgJohn]

The site is using Apache 2.2.22 and PHP 5.3.13

[leolam]

Nik, I did not see the message on this forum so sorry for that...(thx for not replying per email with a note at least)

Issue is resolved with a change in htaccess:

Missing is:

Code: Select all

# requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]

When you add this issue is resolved

Now I am not a specialist and you are in this field so this line was in the previous .htaccess and was stripped for whatever reason for which I am curious about.

Adding this line and giving the .htaccess I attach solves this issue so something is wrong in the current distro as I posted in issues.joomla.org....

Thanks for caring and not responding (courtesy)

Leo

[leolam]

Note: This line was removed based on Issue which I am trying to reopen to get this adjusted

Leo

[Webdongle]

I don’t know what little feud you and WebDongle have between you but leave me out of it

@all
I have no feud ... I answered the OP because I wanted to find out what the cause was. The OP's replies appeared confusing and then Leo confirmed the issue. As neither the OP who reported an issue nor Leo who confirmed it had bothered to start a tracker in issues.joomla.org ... I created one.

Despite my objections to the LGPL and the administration proposal I still put a lot of time and effort into finding the cause of the problem. Leo confirmed he had the same issue but was not clear on how he reproduced it so I did my best to find out how to reproduce the error.


@nikosdion
I have found your documentation informative and instructive and have been scouring it to find an answer to this.


@CobourgJohn
Although a line in your sites .htaccess appears to be a work around it look as if the location of the .htaccess that contains

Code: Select all

AuthType basic
    AuthUserFile"

is the cause of the problem.

[mandville]

moderator comment: removed abusive/degenerating comments

[leolam]

Note to all users: Nicholas of Akeeba and I have been able to get in touch on Skype and we are moving forward in a positive format. No further problems. Rest assured if any misunderstanding was caused related to Akeeba products was never intended. In contrary:

Akeeba Backup, Akeeba Admin Tools and the other products are being created by one of Joomla's top contributors (Nicholas K. Dionysopoulos) who 'invented' the Joomla auto-upgrade amongst many other things. We,install the Akeeba products on each site we develop. Extension suites you cannot miss in your Joomla! site!

Leo

[leolam]

@ All ,
Issue has been identified and posted for revisions on the Tracker

Leo

[leolam]

Leo confirmed he had the same issue but was not clear on how he reproduced it so I did my best to find out how to reproduce the error.

I did as soon as we knew what was causing it as promised I posted on https://github.com/joomla/joomla-cms/issues/4955

Leo

[RedEye]

Well this is not the first thread about this problem I saw and all who had this problem where using cPanel. I tested this on 3 different servers, 2 without any server control software (ubuntu(live server) and kali(local server), 1 with Plesk on ubuntu) and can't reproduce it.

[leolam]

Again this has been resolved with [corrected] still open

Leo

[RedEye]

Maybe resolved for your specific server configuration, in general this line doesn't cause this problem...

[leolam]

Not for "my" server config and I am assured that it is not server but .htaccess so it will be resolved for people who have this situation

Leo

[leolam]

Well this is not the first thread about this problem I saw and all who had this problem where using cPanel. I tested this on 3 different servers, 2 without any server control software (ubuntu(live server) and kali(local server), 1 with Plesk on ubuntu) and can't reproduce it.

so install cPanel and you will) The issue has been acknowledged in the Joomla Bug Squad and has been addressed

Leo

[RedEye]

so install cPanel and you will

yeah sure...

[Webdongle]

Not for "my" server config ...

But it happens on your server configuration but not on others. It was your server configuration being similar to the OP's that enabled you to recreate the issue on your servers.

... I am assured that it is not server but .htaccess ...

From the thread and the issue tracker it appears that is not the .htaccess but the way the server handles directory Password protect in combination with mod_rewrite. And the Joomla .htaccess is being modified to accommodate for the anomaly caused by your type of server configuration.

This type of modification to Joomla files to accommodate misconfigured servers is not a precedence ... FTP layer is included in Joomla to accommodate for servers that have ownership issues.

[leolam]

This type of modification to Joomla files to accommodate misconfigured servers

You have no idea what you are saying nor where you talk about. Since when you think you have the knowledge that you can state that the servers of our company are 'misconfigured' ?

From the thread and the issue tracker it appears that is not the .htaccess but the way the server handles directory Password protect in combination with mod_rewrite

Also wrong since the patch changes the htaccess so this 'problem' does not occurs.

But it happens on your server configuration but not on others. It was your server configuration being similar to the OP's that enabled you to recreate the issue on your servers.

Search the forums Kevin and you will see multiple threads similar to this one on different hosting providers.

Suggest you buy some training time from one of our certified system administrators so you get an idea about server configurations?

Leo

[RedEye]

Pls people lets not start a fight again here

Leo, can you do me a favour? Reproduce the error again and check apache logs and tell us if you see a 401 in it. Chances are high that apache is trying to get 401 error page (something like 401.shtml) what doesn't exists and then throws the 404 error.

[Webdongle]

If I misinterpreted your PM then yes I apologise unreservedly. I have blocked your PM's because I deem "Consider this as a final kind request before I do get mad and you do not want me mad and mind your own business btw!" to be a veiled threat and an attempt to intimidate me. Again, if I misinterpreted that then yes I unreservedly apologise and retract my remark.

Now back on topic ... I have received an an email that contains "The rewriteCond line does fix it, because of this part (/[^.]*) in it, but we should check for better options here".

Now please can we all try and work together on this. If You or someone could suggest a way to configure xampp or wamp to reproduce the error that would be helpful. eg. when Apache puts the PW protect .htaccess in the htdocs(www) root does it code it differently to when it puts it in the /administrator directory ? As it is putting the PW protect in the htdocs(www) folder in localhost just makes all the folders below it.

If the error can be replicated in localhost then many others can help test a patch. And that would help eradicate human error.

[Webdongle]

In addition I have found this about Password protected with cPanel. Yes I know it was a wordpress site that experienced it but the type of site is not relevant. What is relevant is what caused it.

I had this same problem under cPanel. In my case it was due to the "~/.htpasswds/public_html/secure-dir/passwd" file/directory not having the correct permissions. I called the hosting company and they chown'd the file with the correct permissions and it worked.

http://stackoverflow.com/questions/7252 ... cts-to-404

Also http://www.myguysolutions.com/2010/02/1 ... rectories/ may be of interest.

Big thanks to RedEye for discovering that cPanel + Apache + Password protected directories = a call for either a 401 or 403 which when not found will throw the 404 error that the OP is experiencing.

[leolam]

Our permissions are correct

Leo

[RedEye]

Big thanks to RedEye for discovering that cPanel + Apache + Password protected directories = a call for either a 401 or 403 which when not found will throw the 404 error that the OP is experiencing.

To make that clear, I didn't wrote that, what I wrote was: in nearly all cases cPanel is involved. Means you could also run into this on a server without cPanel, depending on the configuration.

The simple fact is that this error is a specific server side configuration issue (apache) related to error documents. For me adding back this RewriteCond line is not the right solution, but I have not to decide it and I also don't really care about this to be honest.