> -----Original Message-----
> From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 29, 2000 6:16 AM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ANNOUNCE] Apache::Dispatch
>
>
> On Fri, 28 Jul 2000, Geoffrey Young wrote:
>
> > hi Matt...
> >
> > I can't access my normal email from home, so forgive
> > the non-quoting of your message... :)
> >
> > the way I set it up, when running in DispatchMode =
> > Safe (the default, which I didn't mention in the
> > docs), you wouldn't be able to call /File/Find/find
> > without explitily allowing File or File::Find in
> > DispatchAllow. I think this addresses the namespace
> > issue - if someone wants to open up File::Find, or
> > whatever, that badly, they can always do it anyway, I
> > suppose.
>
> OK, I think that covers the namespace issue - although I
> don't see a use
> for a non-safe mode!
thanks for the input. after thinking about it over the weekend, I think we
just need a few changes to make it better...
I'll remove Foolish (the name was a dead givaway that it would be gone soon
:), but I think that Brave would greatly enhance the development process by
allowing you to test handlers without having to stop and start the server to
add location tags to reload the module. I'll be sure to add documentation
to that extent.
>
> [basically the way I saw it working was you specified a
> namespace prefix
> for each <Location>, so you'd have DispatchPrefix MyApp, and
> http://server/location/Foo would call MyApp::Foo->handler,
> assuming that
> /location is the entry in <Location> for the above config line]
I did re-read the archives and I saw you mention this. I think I may add an
additional directive
DispatchClass that only works from a <Location> tag that does just that. It
would be in addition to the existing API and would allow only one class per
location. I'll also add documentation suggesting that it exists for
security reasons, so using it like
<Location /Foo>
DispatchClass Foo
defeats the purpose :)
>
> > But maybe we're missing eachother on this? Or you
> > have something in mind that I don't? I'll admit, I'm
> > far from a web security expert, and this does need to
> > be quite secure to be a benefit to anyone...
> >
> > as for method restrictions, I can't remember if it was
> > talked about - I'll have to go over the archives
> > again.
> > however, having to specify Foo::Bar->method for each
> > method you want to use seems like overkill to me,
> > almost as limiting as having to add all those location
> > tags.
>
> Thats not what I meant. If you just force a method prefix,
> the same way I
> suggest above using a namespace prefix, and default to cmd_
> or something,
> then its much easier to design a complex app in a class where you have
> web-space functions (those beginning with cmd_) and non-web space
> functions (i.e. private functions that implement parts of your
> application, where you don't want people directly calling the
> method). Without that, it would be trivial for someone to
> call new() or
> something, which might not be intended (and might have side effects).
right, now I remember. I still think that implying handler() should be an
option, however, since some people do write one handler per module for
mod_perl. How about changing DispatchMethod Subroutine to Prefix and having
that prefix all method calls with dispatch_ , which seems a bit more self
documenting?
>
> > I suppose that setting DispatchMethod = Handler
> > (the default) along with Safe mode would offer a good
> > amount of protection against blunders, allowing only
> > Foo::Bar->handler. I guess I was just trying to offer
> > a fair amount of flexibility, but with flexibility
> > comes the ability to kill your server. of course, a
> > regular CGI script can do that too if you're not
> > careful. :)
>
> Thats too restrictive - that way you have to have one class
> per URL - not
> a nice way to work.
>
> > I don't really think that, in general, imposing method
> > restrictions is necessary, for there isn't really a
> > way to pass any arguments to the method anyway, right?
> > don't all mod_perl handlers get the request object as
> > the only argument (unless prototyped as $$)?
>
> Just because you can't pass arguments, doesn't mean bad stuff can
> happen... Imagine you write a sub clear_cache {...}, that empties some
> sort of cache. It doesn't take any arguments,
> Apache::Dispatch passes in a
> request object as the first param, but its ignored by the
> function, and
> the 733t h4x0r has cleared your cache. (not a terribly
> dangerous example,
> but hopefully you get the picture).
yeah, I see it now...
do you think the above addresses all your issues?
--Geoff
>
> --
> <Matt/>
>
> Fastnet Software Ltd. High Performance Web Specialists
> Providing mod_perl, XML, Sybase and Oracle solutions
> Email for training and consultancy availability.
> http://sergeant.org | AxKit: http://axkit.org
>
