Forum Moderators: phranque

Message Too Old, No Replies

rewrites and http authentication. again

         

ergophobe

5:56 am on Jan 5, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I've been going round and round on this. I've added and subtracted slashes. I've tried it as a whitelist and blacklist. No luck.

I'm simply trying to get a drupal install to NOT rewrite to drupal for certain password protected directories. No luck. Sometimes it serves up the file, and sometimes it simply serves up a 401 (handled with 401.html) or a 404 (handled by Drupal).

I don't understand why, when I ask for a file that is definitely present on the disk, someitmes it rewrites and sometimes it doesn't. Furthermore, it works differently for the other user testing this and for me. We get 401s on different paths. He is someimtes able to access these paths by entering a URL with no 'www' and I am only able to see the 'www' versions.

I'm wondering if there's a way to set the authentication params in this file for the subdirectory and if that might help... although

Current version

# Redirect requests for non-blank non-canonical non-www hostname to same
# URL-path on canonical host, preserving requested http/https protocol
RewriteCond %{HTTP_HOST} !^(www\.traildesigns\.com)?$
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^(.*)$ http%2://www\.traildesigns\.com/$1 [R=301,L]

# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.

RewriteCond %{REQUEST_URI} !^/george [NC]
RewriteCond %{REQUEST_URI} !^/lindsly [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]


I've also tried it using the opposite logic as in


RewriteCond %{REQUEST_URI} !^/george [NC,OR]
RewriteCond %{REQUEST_URI} !^/lindsly [NC]
then don't rewrite and skip the next rules as in Jim's post on making Wordpress rewrites more efficient. That didn't help or hurt particularly.

Any suggestions for getting this to work?

I tried adding this to the subdir to see if that would help:

RewriteEngine on
RewriteOptions inherit

No change.

jdMorgan

8:48 pm on Jan 5, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



First step: Disable MultiViews and AcceptPathInfo unless your site requires them.

Then simplify and optimize your second rule:

# Internally rewrite requested URL-paths of the form 'x' to the filepath '/index.php?q=x', except for certain
# subdirectories and for the most-frequently-requested filetypes which Drupal does not itself generate.
#
RewriteCond $1 !^george|lindsly|\.(php|gif|jpe?g|png|ico|css)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [QSA,L]

If disabling those other requested-URL-rewriting functions doesn't fix the problem, you may need to look into changing the relationship between your auth code and your Drupal rewriting code -- mod_auth will always execute first on any properly-configured server, and your other code needs to be designed and located with that in mind.

Be aware that an internal rewrite modifies the internal filepath to which a requested URL will resolve. However, it does not *change* the URL. So if your authentication/authorization is URL-based, rewriting the request to a different internal server filepath won't affect/bypass that auth function on the originally-requested URL-path. If however, you want to rewrite a request, and that rewritten request should then invoke authentication/authorization on the new path, then see the mod_rewrite [PT] flag.

Also, be sure that both you and your tester are completely deleting your browser caches after changing any code on the server side. Once authenticated and authorized, you will need to both delete the cache and restart your browser if you want to get consistent test results to help find the problem.

Another possibility is that some script somewhere is redirecting to a non-canonical location, causing a fur-ball of auth-redirect-re-auth transactions. The Live HTTP Headers add-on will reveal that kind of problem quickly.

Jim

ergophobe

9:13 pm on Jan 5, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Thanks Jim!

I never think of using the RewriteRule capture group in a RewriteCond.

After hours of clearing the cache, tweaking and reloading, it finally hit me to try doing this with subdomains instead and then checking the RewriteCond for the host.

It's working for now, but I might give your solution a try soon. We decided to let the site "settle" for a few days and not make any rewrite changes so we can watch other things.