I am unable to confirm

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

My gut instinct says this is going to be caused by a specific server side
configuration. I've just tested replacing a customized htaccess on my site
(which has the admin password protected) with the default Joomla one and
things continued to work as expected. The only production change to that
file that's happened in the last few years was
e5eb98a
which went into our releases in July, so from that aspect there's no reason
that should've stopped working just because of the update.

On Wed, Oct 29, 2014 at 7:25 AM, Webdongle notifications@github.com wrote:

Steps to reproduce the issue

http://forum.joomla.org/viewtopic.php?f=714&t=863231
Expected result

Ability to Password protect a directory and enter that directory by
entering user/pass
Actual result

404 error
System information (as much as possible)

Confirmed by Leo
http://forum.joomla.org/viewtopic.php?f=714&t=863231#p3233384
Additional comments

Thread discussing it is
http://forum.joomla.org/viewtopic.php?f=714&t=863231

—
Reply to this email directly or view it on GitHub
#4955.

"My gut instinct says this is going to be caused by a specific server side
configuration"

Yes that is mine too or the OP has edited Global configuration for Rewrite but not uncommented '#RewriteBase /'. The OP also claims he never edited the .htaccess just replaced it ... as the Joomla install does not write the .htaccess then it is also possible that it was a custom install from the Hosts CP.

As you will see from the thread I am also unable to replicate the issue.

But Leo confirmed the error in the thread without giving details of how to reproduce and without opening a tracker ... so is seemed appropriate to open a tracker.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

I am able to confirm what was posted in the original thread and the OP is not a client of us nor does he/she hosts with us.

I have reached out to @nikosdion via email related since he is such an expert. I posted to him the following experience:

When on a cPanel box you create an Administrator protection in the cPanel File Manager it works without .htaccess and mod_rewrite enabled. When we enable mod_rewrite and enable the default Joomla .htaccess (with in cPanel the administrator folder protected) we get

a 404-error with "category not found". (checked ownership and permissions of the 2 cPanel files and they are good (644))

The cPanel protection consists of 2 elements. A password file which is located outside the root in home/username/.htpasswds/public_html/administrator/passwd" and the htaccess file which is located in the ../administrator file (which loads the passwd from the link given and stores the pw).

Interesting part is that if we use Admin Tools by Akeebabackup it works normally with mod_rewrite and .htaccess in root and I think that is because Admin Tools places the 2 mentioned files both (!) in the Joomla administrator root.

The error happens with the Joomla core .htaccess set. It does not make a difference if mod_rewrite is enabled or not. If you set in Joomla configuration "disable url-rewriting" error happens because htaccess enabled. Since Akeeba Admin Tools works like a charm in J336 and sets the password protection and that works fine with .htaccess enabled I suspect that something in htaccess is blocking this because it is located outside the root in cPanel

Am I a fool (of course I am) or what do we miss? Any suggestions besides an Issue on the Tracker??

--------------------[end of quote from email to Nikolaos today]

So just to make sure we have common understanding: Any site works normal with mod_rewrite and default .htaccess. All our client sites work normal and we never noticed this since we always (!) install AT) Server setup properly therefore. Any site works with mod_rewrite not enabled and htaccess.txt so just with default SEO (i.e. site.com/index.php/etc ) --> all ok

Admin Tools admin protection which uses same .passwd and .htaccess basics both in administrator root folder works flawless with mod_rewrite and .htaccess enabled (see our own sites)

cPanel's admin protection works well with default SEO (i.e. index.php added) but as soon as .htaccess from Joomla root enabled : No go and 404 with message as stated

So again look what I posted to Nikolaos: I do think something in our .htaccess (in possible combination with mod_rewrite in Apache) is causing this but I am missing the knowledge to troubleshoot it. My server people are talking as I post this message to the Liquidweb Account Manager assigned to us as well and he talks to his system admins to see why this is happening since also error-logs and Apache's Tailwatch do not show any blockages either in mod_security for example.

Just to make sure that Kevin is not taking fool for this.

Leo


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

Just to clarify our hosting setup without all details: http://gws-host.com/gws-host-system-technology

Leo :)

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

Issue has been identified: This happens because this was removed from htaccess in current version for some reason:

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

When this is added to the .htacces all works as expected

Leo :)


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

Sorry do not know how to change files etc but for sure this resolves this
(Why was this removed anyhow from earlier htaccess files?

This was removed to allow extensions having different document types. Like dynamically generating an excel or something like that.
Maybe we can add a rule which would rewrite everything except .htaccess files.

So correct .htaccess (which resolves this):

##
# @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
##

##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations.  It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that dissallows changing it in
# your .htaccess file.  If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's.  If they work,
# it has been set by your server administrator and you do not need it set here.
##

## Can be commented out if causes errors, see notes above.
Options +FollowSymLinks

## Mod_rewrite in use.

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects

##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /
## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the request is for something within the component folder,
# or for the site root, or for an extensionless URL, or the
# requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

PR was #488

Sorry for this but I have no idea to post code here


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

Sorry for this but I have no idea to post code here

Edited your comment :)

Tnx Thomas looks way better for sure ;-)

find http://forum.joomla.org/viewtopic.php?f=714&t=863231&p=3233474#p3233474

Issue is resolved as stated with adding the line so do not know what to do next for default Joomla htaccess?

Thomas that issue #488 was closed so I do not know how to reopen this to address this issue?


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

You do not re-open it, you create a new PR for that.

Will open a new PR for this one.

See my PR. This is without any warranty, so please test.

will do tomorrow (1.30 am as of posting)

@test could not resist the challenge despite time. Nice one @Hackwar
Confirmed working and resolved
For me RTC

Perrfekt! many thanks, this new .htaccess works for me also. I was already despair. Confirmed working and resolved

Set to "closed" on behalf of @zero-24 by The JTracker Application at issues.joomla.org/joomla-cms/4955

Closing as #4957 is successful tested by @gwsdesk and @Tabelle Thanks

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4955.

Hmm, since #4957 broke menu items when SEF extensions were used, it had to be corrected after the tests mentioned above have been made. So this issue should not really be closed because of successful tests.

This error also occurs when your password protect .htaccess doesn't specify the ErrorDocument ErrorDocument 401 "Authorisation Required"

Source: https://www.web357.eu/the-protection-of-joomla-admin-folder-returns-404-error

This is incorrect. The error will only show if another .htaccess in any directory above (from the server root onwards) and/or the virtual host configuration specifies a 401 error document which does not resolve. If no 401 error document is specified Apache will issue its own very basic 401 error document and there's no error. The line you pasted essentially does that: it tell Apache to use its built in error document for HTTP 401 with the specified string ("Authorisation required") as the title.

To be clear, the error you get with administrator password protection only occurs if Apache encounters an error (e.g. 404) when trying to find the 401 error document. The reported issue only occurs on badly configured hosts which define a non-existent error document for 401 errors. This results in Joomla! handling the invalid URL, throwing its own 404 Not Found page. Apache sees that the 401 error document URL results in a 404 and doesn't know what to do.

So, as I said several months ago, the problem comes from BADLY CONFIGURED servers. If you don't have a custom error document in place then DO NOT tell Apache that you have a custom error document in place or bad crap will happen. Sounds reasonable, doesn't it?

@nikosdion Yes that makes sense. Thanks for your thorough explanation