httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt McCutchen <m...@mattmccutchen.net>
Subject Re: [users@httpd] How to serve up different content depending on authenticated user
Date Fri, 06 Feb 2009 02:42:53 GMT
On Thu, 2009-02-05 at 20:10 +1000, Steve Dalton wrote:
> Matt - That method didn't work for me... it got into an internal
> recursion and bombed out after 10 redirects. I think you do perhaps
> need to test for something to stop it going on forever.

Does this happen even with the rule in the vhost configuration?  (I was
pretty sure rules there were executed only once.)  If so, please set
"RewriteLogLevel 9" and post the portion of your rewrite_log
corresponding to one request so I can see what happened.

    On Thu, 2009-02-05 at 06:18 -0500, Eric Covener wrote: 
    > Needs lookahead (LA) to see %{REMOTE_USER} in per-vhost Rewrite.

Indeed, I missed that in the docs.  If you stick with the rule in the
vhost configuration, it should become:

RewriteRule ^(.*)$ /var/www/accesstest/%{LA-U:REMOTE_USER}/$1

Or you could put the rule in htaccess and find a proper solution to
avoid looping without letting users access each others' directories.
What I do on my Web site is condition the rule on a custom environment
variable being unset and have the rule set that variable.  (Unlike the
"user_" prefix, clients can't set environment variables.)  Note that an
internal redirect prepends REDIRECT_ to environment variable names.  For
instance, you could do:

RewriteEngine on
RewriteCond %{ENV:REDIRECT_PREFIXED_USER} !1
RewriteRule ^(.*)$ /var/www/accesstest/%{REMOTE_USER}/$1 [E=PREFIXED_USER:1]

> Andre - I think you are right... that's why you still need to have a
> "Require user <user>" in a seperate directive for each directory....

No, Eric is right:

    On Thu, 2009-02-05 at 06:32 -0500, Eric Covener wrote:
        > In per-vhost rewrite, you've replaced the bit of code that would kick
        > that request out with a 400 by using rewrite. However,  the ..'s have
        > still been flattened before the rewrite starts.  You would see a
        > relative path such as "index.html" as the URI in your rule.
        >
        > If you had only per-directory rules, the core code that maps URIs to
        > the filesystem would return 400 before you got to them

Specifically, ap_process_request_internal calls ap_getparents to strip
all .. components before any filesystem walking or rewriting occurs:

http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/server/request.c

Thus, users can't circumvent your rule using "..".

That said, if you use the htaccess RewriteRule, it will run at a very
late stage of request processing, so a client who specifies another
user's directory might trigger something in an htaccess file there
before your RewriteRule has a chance to prepend the client's own
directory.  Thus, you should be careful what you allow in htaccess files
in user directories.  On the other hand, the use of lookahead in the
vhost RewriteRule may raise a similar issue unless you put the user
directories outside the document root.  (I'm not totally sure of my
reasoning here; corrections welcome.)

> it's a pain but the only way I can see it working. I think perhaps you
> could write a macro to automatically add this directive for each
> directory - but I haven't got into that yet.

That may still be worth doing as a second line of defense.  Try this:

sed -re 's,^(.*):.*$,<Directory /var/www/accesstest/\1>\nRequire user \1\n</Directory>,'
</var/www/passwd/htpasswd

-- 
Matt


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message