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!
[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]
> 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).
> 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).
--
<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
