(solved) Rewrite rules and httpauth on ./admin/ not getting along

[kermit]

On 1.1.4.1 (seen this as far back as 1.08, though):

Take a working site with mod_rewrite enabled; add http authentication to ./admin directory then http://yourdomain.com/admin brings up a 404

Remove the authentication configuration from ./admin/.htaccess and you can get in to admin area (just no server login prompt)
OR
Remove all rewrite configuration from ./.htaccess and you can get into admin area (with server login prompt) but then you have to not use pretty URLs and mod_rewrite on the site.

Some server info:
WHM 11.11.0 cPanel 11.15.0-C17665
CENTOS Enterprise 5 i686 on standard - WHM X v3.1.0

Apache/1.3.39 (Unix) PHP/4.4.7 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.30 OpenSSL/0.9.8b

CMSMS is running with PHP 5.2.4 (CGI); note that PHP version doesn't matter here.

./.htaccess contains:

Code: Select all

# Use PHP5 by default
AddHandler application/x-httpd-php5 .php

# Begin Rewrite rules for CMSMS
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f [NC]
RewriteCond %{REQUEST_FILENAME} !-d [NC]
RewriteRule ^(.+)$ index.php?page=$1 [QSA]
# End Rewrite rules for CMSMS

./admin/.htaccess contains:

Code: Select all

AuthType Basic
AuthName "CRD Web Site"
AuthUserFile "/home2/username/.htpasswds/public_html/sub-test/admin/passwd"
require valid-user

assume_mod_rewrite enabled; use_hierarchy tried both ways; extension doesn't matter.

This particular instance is a new install of 1.1.4.1, but we've also seen this happen on a few 1.08 sites that we moved to this new server a couple weeks ago. http auth on those sites was protecting some third-party stats in a subdirectory off of the CMSMS root directory (edit: confirmed to NOT work right with ./admin either on those sites).

This authentication was working on our former (non-cPanel) server running Apache 1.3.something/PHP4.

This authentication method does work on a different site on the same server that is pure static html pages.

Disabling rewriting in ./admin/.htaccess doesn't work; even going straight to a known exact URL in the admin area (http://yourdomain.com/admin/login.php) brings up the 404.

I don't like not being able to double-up on the authentication for admin areas... Any ideas as to what's going on or what cPanel has managed to mangle?

[tsw]

try adding

RewriteEngine Off

to the .htaccess in /admin directory

[kermit]

try adding

RewriteEngine Off

to the .htaccess in /admin directory

tried that already; sorry. missed that detail in my post.

[tsw]

I just tested this with the default .htaccess file (from doc/htaccess.txt) and with your auth .htaccess in /admin.

Works correctly here

(apache2, php5, linux server)

[kermit]

I just tested this with the default .htaccess file (from doc/htaccess.txt) and with your auth .htaccess in /admin.

Works correctly here

(apache2, php5, linux server)

well, you and I both know that it's right..

      but allow me to quote myself here....

Any ideas as to what's going on or what cPanel has managed to mangle?

I should further add that I've seen this happen on TWO different servers, from different providers, both running CP11. Also; a previously used server (at least 1 1/2 years ago), running CP10 did not have this problem, IIRC.

Since it (httpauth) works without CMSMS' rewrite rules in place; I figured I'd better ask in here first, before bugging someone about cPanel.. they'd likely just throw the blame right back here, anyway.. you know how it goes.....

[kermit]

Note this is not affecting version 0.12.1 on the same server (that version uses different rewrite rules). seen it on 1.08 and up so far.. have a couple others between 1.0 and that to try out.

Anyone else with cPanel11 on their web host having the same problem?

[kermit]

Little update; two fresh installs of 1.2 running under PHP5(CGI) each to their own subdomain:  one to the web root, the other to a subdirectory.

The "subdirectory" (e.g. http://test1.domain.com/cms) install appears to be working OK, it's just the root install (e.g. http://test2.domain.com) that is exhibiting this problem.

[tsw]

just a guess, but maybe cpanel has some weird extra "security" rules that forbid using /admin/ as a path for the admin panel functionality.

then again, I dont use cpanel and been happy without it

[kermit]

it seems apache was looking for the associated error document before bringing up the httpauth prompt; and since the site didn't have any custom ones in place (supposedly relying on server-wide defaults); apache was 404'ing on the error document, NOT the actual requested page.

added my own custom error documents to the domain root and all is well...