Inability to password protect directory on new Joomla Sites

[leolam]

The simple fact is that this error is a specific server side configuration issue (apache) related to error documents.

Problem is that Apache does not show any errors in logs nor tailwatch etc etc

Leo

[RedEye]

The simple fact is that this error is a specific server side configuration issue (apache) related to error documents.

Problem is that Apache does not show any errors in logs nor tailwatch etc etc

That means you say it's not a configuration issue?

Could you add an 401.html and then add ErrorDocument 401 /path/401.html on top of the .htaccess in the folder you trying to protect or above the rewrite rules in joomla's .htaccess and tell me if that also fixes the problem or not

[mandville]

[moderator comment]
i have had to move some posts that did not fit within forum guidelines. if you wish to post facts and solutions relating to the OP issue, feel free. please refrain from anti social posting.
tuppence on the table people!

[Webdongle]

...

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. ...

The patch solves the problem because it adds code to the .htaccess that overrides the Rewrite settings ... much in the same way as adding code to a local php.ini file can override the server php settings. Therefore the .htaccess was not the problem but a tool to use that fixes the problem.

Unfortunately the 'fix' broke more than it fixed and other methods are being investigated.

...

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.
...

My wording there does need clarification my apologies ... I will elaborate so that the OP can know the progress.

The Devs and the other bugsquad members are working hard to come up with a solution but are unable to test their theories because :
None of the Devs have been able to recreate the issue on their servers. And you are the only member of the bugsquad team that can recreate the issue on your servers.

From your post in the thread in the issues.joomla.org it appears that ... Dan Wells of Liquid Web advised "can easy resolve this behavior when you add to public_html a 401.shtml upon account creation" http://issues.joomla.org/tracker/joomla-cms/4957

Your problem is solved and that is how the OP can solve his. Unfortunately this does not help the dev team because they can not install a 401.shtml with every Joomla install. Bakual has come up with a possible fix that will not break other things but nobody else can reproduce the error in order to test the patch.

[leolam]

I am aware of that and therefor we are still discussing this on Github and as soon as I have a reply on my latest request I will test this again

[mandville]

If its caused by using the hta wizard on cpanel (not akeeba ) the possibly it's a fault of the wizard not checking and creating a 403 page or 403 redirect and not joomla fault ?

[leolam]

Could be. Since I am not happy with a 401.shmtl as well I have also asked to open a ticket with cPanel. I keep all posted unless we find something in cPanel

[Webdongle]

If its caused by using the hta wizard on cpanel (not akeeba ) the possibly it's a fault of the wizard not checking and creating a 403 page or 403 redirect and not joomla fault ?

It has been demonstrated that when cPanel and the server set up are correctly then there is no error.

I have tested the situation on my siteground server running cpanel without making any changes or patches

the .htaccess was created in
/home/xxxxx/public_html/xxxx/administrator/passwd"
the .htpasswd was created in
/home/xxxx/.htpasswds/public_html/xxxx/administrator/passwd"

Using the core htaccess file and setting a passwd on the administrator folder I had NO problems at all.

http://issues.joomla.org/tracker/joomla-cms/4957

Given:

1. It works when the pw protect is created with cPanel
2. It works when the .htpasswds is outside the site root
   1. I have tested on
   2. xampp running Apache 2.4.9
   3. wamp running Apache 2.4.9
   4. Shared Hosting running Apache 2.4.9
3. Given that Wordpress and other platforms suffer the same 404 response with pw protected directories after a .htaccess (that contains the Rewrite on statement) is added
4. Joomla devs and other members of the bugsquad have tried various combinations without being able to successfully recreate the issue.
5. "There have been significant changes in authorization configuration" http://httpd.apache.org/docs/2.4/upgrading.html
6. That on the servers that suffer the problem ... a 401.shtml file needs to be added to the site root

Then
The cause appears to be the way in which the server handles mod_rewrite. If the servers (that experience the 404 error when pw protection and mod_rewrite are used together) have updated Apache from 2.2 to 2.4 .... then following 'Run-Time Configuration Changes' advice on http://httpd.apache.org/docs/2.4/upgrading.html would most likely negate their need to to use the 401.html work-a-round.

[CobourgJohn]

As the person who originally posted the problem, perhaps my concerns are relevant. I don't have any way to change the configuration of my server or of CPanel. I use what I was given by Hostgator. But I'm not too concerned; now that I know what to do, I'll simply use the old htaccess file - I just thought Joomla developers would like to know that their latest htacess file is not universally usable. I'm glad at least one person has reproduced the problem - maybe he should be given credit for that and maybe people should understand that not everyone has the same server configuration nor has everyone the ability to change their configuration. 16 of my Joomla 3.3.6 sites work well with the htaccess files installed in their original installation (pre 3.6.6) - only the 3 new fresh 3.3.6 had the problem and that's with the new version.
Telling me to change how my server works or is configured does not solve anything.

[leolam]

Webdongle....As posted on the Github also the System Administrators at Liquidweb (we use their datacenter) have been able to recreate the issue on their own systems. https://github.com/joomla/joomla-cms/pu ... t-61339415

Issue what is causing this is identified and I have posted their replies to my system admins on the Github.

We do need to find a solution as suggested by one of Liquidweb's system admin who have gone all out (!) to help to identify

Leo

[Webdongle]

... As posted on the Github also the System Administrators at Liquidweb (we use their datacenter) have been able to recreate the issue on their own systems. ...

If one site on their servers has that problem then of course they will be able to reproduce it on their servers.

The fact remains that the majority of other servers ( including xampp and wamp ) do not have that problem. With the Devs and the other bugsquad members unable to reproduce the error then it makes it difficult to test any fix.

As the person who originally posted the problem, perhaps my concerns are relevant. I don't have any way to change the configuration of my server or of CPanel. ...

Yes they are and it is your concerns combined with Leo being able to reproduce the error that prompted me to bring the issue up with the Devs and other bugsquad members.

... - I just thought Joomla developers would like to know that their latest htacess file is not universally usable. ...

And as only you and Leo are the only ones able to reproduce the error then your input would be very useful. If you could do 2 simple things it would help tremendously.

1. Test using a .htaccess that only contains the command
   Rewrite on
2. Use the .htaccess from the 3.3.6 txt.htaccess and add

   Code: Select all

   # and the requested non-existant file isn't a custom error file
   RewriteCond %{REQUEST_URI} !^401.shtml$
   RewriteCond %{REQUEST_URI} !^403.shtml$
   

   so that it reads

   Code: Select all

   RewriteCond %{REQUEST_FILENAME} !-d
   # and the requested non-existant file isn't a custom error file
   RewriteCond %{REQUEST_URI} !^401.shtml$
   RewriteCond %{REQUEST_URI} !^403.shtml$
   # internally rewrite the request to the index.php script
   

...
Telling me to change how my server works or is configured does not solve anything.

You may have missed the post that said by simply placing a file named 401.shtml into the site root will resolve the problem.

[leolam]

... As posted on the Github also the System Administrators at Liquidweb (we use their datacenter) have been able to recreate the issue on their own systems. ...

If one site on their servers has that problem then of course they will be able to reproduce it on their servers.

No incorrect remark since we use different configs in Apache on several servers with different configs depending on server size, dedi versus VPS, etc, etc, etc. We have 192 dedi's and VPS' and do not run on "their" servers. Our settings are completely modified after a server is commissioned with our own configs and with security optimizations by Configserver

The remark has therefore no merit.

We will test tomorrow your suggestion with pleasure but you should read what was stated regarding what was causing this as per report by Liquidweb.... That should be addressed

Cheers

Leo

[Webdongle]

...
We will test tomorrow your suggestion with pleasure ....

Just to be clear my suggestion was to test with a .htaccess that only contained 'Rewrite on'. The added code is what was suggested by Bakual. If you and the OP could test both suggestions that would be a great help.

Being unable to reproduce the error with any of the server settings that I've access to is very frustrating. If that frustration shows in any of my posts then I can only apologise. With luck other users ( who experience their server throwing a wobbly and spitting out a 404 page ) will see this thread and help join in the testing.

[CobourgJohn]

Changing the code to

RewriteCond %{REQUEST_FILENAME} !-d
# and the requested non-existant file isn't a custom error file
RewriteCond %{REQUEST_URI} !^401.shtml$
RewriteCond %{REQUEST_URI} !^403.shtml$
# internally rewrite the request to the index.php script

does not help
But adding a 401.shtml file does work for me.

[Webdongle]

Thank you ... have passed that on to the devs

[leolam]

Being unable to reproduce the error with any of the server settings that I've access to is very frustrating. If that frustration shows in any of my posts then I can only apologize.

NP all accepted. With this kind of stuff it is hard to diagnostic. I stayed out because I had no idea and let it be handled by my server team and the good people of Liquidweb.

I am cool but get frustrated when people just state" at my server at -xyZ- we don't have this so must be bad configured- You have read the LW system admin reaction to that remark on Github. That remark was placed between ""

Leo

[Webdongle]

... when people just state" at my server at -xyZ- we don't have this so must be bad configured- You have read the LW system admin reaction to that remark on Github. That remark was placed between ""
...

If something is proven to work ... then when it doesn't work it means that something is not correct where it is not working. In both instances of when it worked and when it didn't work Joomla was the same and the .htaccess was the same. Therefore the only difference is with the server settings.



I saw this reply from the LW tech that you posted.

... it seems the configuration line:
ErrorDocument 401 /401.shtml
was the thing that was breaking it. I removed it from the main conf (where my colleague put it earlier) and from the default include where cPanel adds it as well.

It is working now, but the Joomla! developers should look into exactly why this "bad configuration" broke their code.

Which states that alteration to the configuration fixed it ... and recommends Joomla devs find out why the 'bad configuration' broke their (Joomla) code.

In other words ... 'The configuration was incorrect we altered the configuration and that fixed it. We have no idea why the bad configuration broke Your Joomla.
(That's how it reads to me)

How else can it be interpreted ? Other than the configuration server side was changed ... and that the "bad configuration" was the cause of breaking the site.

[Planck Mann]

Thank you for the good advices.