[new module] Apache::Dispatch
hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. How Randal used to say: Dangerous, Willis? or was it Robinson :) Personally I'm against this idea. Unless you allow only a list of specified Module::method (s), but even then things will get modified the original intention forgotten, systems hacked and ruined. * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [new module] Apache::Dispatch
On Mon, 5 Jun 2000, Stas Bekman wrote: On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. It shouldn't be dangerous at all if you specify: PerlSetVar DispatchPrefix MyModule Then http://localhost/Foo/bar calls MyModule::Foo-bar() -- 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 http://xml.sergeant.org
RE: [new module] Apache::Dispatch
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 12:19 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]'; 'Vivek Khera'; 'Matt Sergeant' Subject: Re: [new module] Apache::Dispatch On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. well, it was the article in this month's LJ that made me think of it again... http://www2.linuxjournal.com/lj-issues/issue74/4002.html of course, while I don't share his views stated in the third and fourth paragraphs, I thought answersing those types of concerns would be a benefit... You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. How Randal used to say: Dangerous, Willis? or was it Robinson :) Danger Will Robinson :) Personally I'm against this idea. Unless you allow only a list of specified Module::method (s), but even then things will get modified the original intention forgotten, systems hacked and ruined. ok, I never claimed to be a security expert, and we certainly don't want to expose mod_perl or give it a bad name. However, if the client/user uses the module parameters to expose his system, does that mean that the module is a bad idea? but I don't see that by allowing only Apache:: modules adds a security risk (but I don't tear apart systems for a living :) --Geoff * if possible, I'd like to see it make some intelligent decisions about whether it should take over the request. that is, perhaps move away from a Location restriction and try to call Foo-doit() if the normal resoltion /Foo/doit results in a 404. I'm not sure how this would interact with mod_dir, but I guess it would also depend on how folks want to use it... * do we want to default to handler()? if so, what to try first: Foo::doit-handler() or Foo-doit() anyway, that's all for now... feedback/thoughts welcome... --Geoff _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: [new module] Apache::Dispatch
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 12:25 PM To: Stas Bekman Cc: Geoffrey Young; '[EMAIL PROTECTED]'; 'Vivek Khera' Subject: Re: [new module] Apache::Dispatch On Mon, 5 Jun 2000, Stas Bekman wrote: On Mon, 5 Jun 2000, Geoffrey Young wrote: hi all... I'm not sure if some you remember the idea Vivek and Matt had about creating a handler that mapped, say, http://localhost/Foo/doit to Foo-doit() anyway, the relevant part of the thread, including some code, can be seen here: http://marc.theaimsgroup.com/?l=apache-modperlm=95598609306936w=2 I was thinking of officially implementing the idea and wanted to get some design feedback first... My thoughts so far: * limit the response to content handling phase only (I'm not really sure of what utility other phases would be anyway) * limit the top-level qualifier for the module that can be executed, but give this control to the user. perhaps using PerlAddVar to allow only Apache::, Foo::, etc modules only is safe enough? Geoff, I think you will open a Pandora box by releasing this module. I don't see it'd give some real savings, but users will get hurt, badly. You shouldn't let the control into user hands! (I mean the clients!) There will be alway a module that you will not know about, or a function/method inside it you won't think about. It shouldn't be dangerous at all if you specify: PerlSetVar DispatchPrefix MyModule Then http://localhost/Foo/bar calls MyModule::Foo-bar() oh, I hadn't thought of using that combination. I guess that would also hide the full package names from the outside and would add an extra level of security... -- 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 http://xml.sergeant.org
