CMS Made Simple Forums

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: ./admin/.htaccess contains:
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?

try adding

RewriteEngine Off

to the .htaccess in /admin directory

tsw wrote: try adding

RewriteEngine Off

to the .htaccess in /admin directory

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

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)

tsw wrote: 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....

kermit wrote: 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.....

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?

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.

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

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