Re: overriding document root dynamically?
At 02:09 PM 1/28/00 -0800, you wrote: >Uh, why not? No module after the Trans phase looks at document root, >that I'm aware of. index.html is handled by mod_autoindex during the >content phase upon noticing that it's a MAGIC_DIR_TYPE, causing an >internal (or external, if no slash) redirect. And *that'll* come back >through your Trans handler to get the same treatment. I see. I misunderstood how DirectoryIndex is implemented. Actually I always mix this up... >Well, that's true, because those are Trans phase items. But do you >really want an alias to be run? It'll be wrong! Well, you could arrange for a RewriteRule to work correctly regardless of which document root was chosen. But I'm splitting hairs. Anyway we want to implement our redirects outside of the httpd.conf to minimize restarts. I'll give this a try. Jon
Re: overriding document root dynamically?
On Fri, Jan 28, 2000 at 12:11:07PM -0800, Jonathan Swartz wrote: > etc. I could do this with a set of virtual servers, but then I have to > change the httpd.conf and restart the server every time a user is > added, which is undesirable. Use mod_vhost_alias. You do not have to touch your httpd.conf for a new user but just create a directory named like the server you want, e.g. /home/httpd/www.joe.yourcompany.com/ Andre
Re: overriding document root dynamically?
> "Jonathan" == Jonathan Swartz <[EMAIL PROTECTED]> writes: Jonathan> Sure, but then index.html files won't get found, Uh, why not? No module after the Trans phase looks at document root, that I'm aware of. index.html is handled by mod_autoindex during the content phase upon noticing that it's a MAGIC_DIR_TYPE, causing an internal (or external, if no slash) redirect. And *that'll* come back through your Trans handler to get the same treatment. Jonathan> Alias Jonathan> directives won't get processed. Well, that's true, because those are Trans phase items. But do you really want an alias to be run? It'll be wrong! Besides, you can do the same Aliasing at the time you come up with the $r->filename. Another option is to do a subrequest, setting $r->pnotes with a value that will cause *your* handler to quickly DECLINE, and letting the rest of the stuff trigger. Then look at the $r->filename from that subrequest, and use that to decide if you need to edit your $r->filename on the main request, and return OK. Weird, but cool. :) Jonathan> etc. Basically I don't want Jonathan> to have to reimplement Apache's entire default file handler Jonathan> in Perl. I don't think you need to. I think only the Trans handlers need to worry about docroot. Of course, I'm possibly wrong. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: overriding document root dynamically?
Sure, but then index.html files won't get found, Alias directives won't get processed. etc. Basically I don't want to have to reimplement Apache's entire default file handler in Perl. At 12:43 PM 1/28/00 -0800, Randal L. Schwartz wrote: >I think you can get the same effect by *ignoring* the document root. >Just set $r->filename($whatever), and return OK from the handler. >Then the default handler won't do the URI-to-filename translation, and >everybody goes home happy. > >-- >Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 ><[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> >Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. >See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >
Re: overriding document root dynamically?
This is more along the lines of a cautionary note than anything else,
but mod_perl isn't exactly a secure system, so I'd be very carefull with this
setup: if you're doing what I think you're doing. Do you trust your users? Are
the allowed to execute perl-code? If so, they could gain access to other
people's files in their www directory.
Are there any modules that are similar to user_dir that are more
configurable? --SC
On Fri, 28 Jan 2000, Jonathan Swartz wrote:
> I have an application where I want the effective DocumentRoot to change
> based on dynamic properties in the request.
>
> In particular, we are creating a number of domain aliases, pointing to the
> same IP address, so that each user can view their own version of the web
> site. e.g.
>
>joe.dev.mysite.com would have doc root /home/joe/www
> dave.dev.mysite.com would have doc root /home/dave/www
>
> etc. I could do this with a set of virtual servers, but then I have to
> change the httpd.conf and restart the server every time a user is
> added, which is undesirable.
>
> Here's what I wanted to work:
>
> sub trans_handler
> {
> my ($r) = @_;
> my ($user) = ($r->header_in('Host') =~ /^[^\.]+/);
> $r->document_root("/home/$user/www");
> return DECLINED;
> }
>
> PerlTransHandler trans_handler
>
> but I got
>
> [error] Usage: Apache::document_root(r) at handler.pl line 41
>
> so document_root ain't writable.
>
> Any other suggestions? I'm loathe to recreate the entire default Apache
> directory handler in my trans_handler (looking for index.html, etc.)
>
> Jon
--
Sean Chittenden p. 650.473.1805
auctia.com, Inc.f. 650.329.9651
Re: overriding document root dynamically?
> "Jonathan" == Jonathan Swartz <[EMAIL PROTECTED]> writes:
Jonathan> Here's what I wanted to work:
Jonathan> sub trans_handler
Jonathan> {
Jonathan> my ($r) = @_;
Jonathan> my ($user) = ($r->header_in('Host') =~ /^[^\.]+/);
Jonathan> $r->document_root("/home/$user/www");
Jonathan> return DECLINED;
Jonathan> }
Jonathan> PerlTransHandler trans_handler
Jonathan> but I got
Jonathan> [error] Usage: Apache::document_root(r) at handler.pl line 41
Jonathan> so document_root ain't writable.
I think you can get the same effect by *ignoring* the document root.
Just set $r->filename($whatever), and return OK from the handler.
Then the default handler won't do the URI-to-filename translation, and
everybody goes home happy.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
