http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7804
--- Comment #27 from Jared Camins-Esakov <[email protected]> --- (In reply to comment #26) > I've been thinking about this issue all night. I can understand your > motivations and thinking behind the necessity of using > Module::Load::Conditional. Could you describe the changes that would need to > be made in order to implement it correctly? Here is the current workflow: Let's assume that we're going to be handling a reports plugin called "CoolStuff". I'm going to describe the workflow using Module::Load::Conditional. Everything could be done with just Module::Load, but that would require more work. > 1) A plugin is uploaded to the plugins directory. This will be unchanged, except the plugins directory wouldn't be +Exec, or even directly accessible via Apache. > 2) The plugins.ini is parsed, this tells which which about the starting file > only. There are two options here. For option 1, this would work basically the same, though the exact meaning of of the "start" parameter would change slightly. Option 2 might be better though. In this case, we don't actually need the start parameter at all, because we require a consistent Perl interface, so our plugin implements Koha::Plugin::CoolStuff::Dispatcher, and the plugin manager knows that we always start with the dispatcher. I'm going to assume we're going with option 2 because it's easier to implement. > 3) Koha gives a link to the plugin starting file. This is where things start *really* changing. Koha gives a link to /plugin/run_report.pl?plugin=CoolStuff, and when run_report.pl is called, it uses Module::Load::Conditional to load Koha::Plugin::CoolStuff::Main, and create my $plugin = Koha::Plugin::CoolStuff::Main->new() [this is where initialization code could get called] > 4) The file is executed, is authenticates itself, and loads its template > files independently of the internal Koha templating system ( TT is used for > templates only because we can be sure TT is available, and also it is simply > better than other templating systems, though a plugin could just as easily > output html from the perl file or use HTML::Template ). Rather than executing the file directly, /plugin/run_report.pl runs plugin->run_report(). This means that the plugin author doesn't have to worry about authentication. If it's required, it's already been done by the plugin host. The best way to handle non-Perl resources would be to have everything pulled from /plugin/resource.pl?plugin=CoolStuff&resource=image.png [and a TT plugin could make translating "image.png" to "/plugin/resource.pl?plugin=CoolStuff&resource=image.png" invisible to the user... this step would be optional, but it'd be a lot easier to manage things this way] > 5) At this point, control is passed completely to the plugin, which is > responsible for any subsequent perl file execution. > > Step 5 is where things will definitely change. As it stands, step 4 can be > modified to use M:L:C easily, but step 5, not so much. I think step 5 will > involve the plugin itself calling M:L:C via Koha::Plugins to continue its > execution. Yeah, I think this would be the easiest way to deal with things. The plugin will extend Koha::Plugin::Report (and if a plugin implemented both a Report and a Tool, it could extend Koha::Plugin::Tool, too) but use Koha::Plugin::Host, so that it could do something like my $cooler = Koha::Plugin::Host->load('CoolStuff', 'CoolerClass'); Then it makes use of $cooler in whatever way is necessary to implement the report functionality. For simple plugins, everything could be implemented in Koha::Plugin::CoolStuff::Main, and there wouldn't be any need for using Koha::Plugin::Host->load() from within the plugin. For fiendishly complex plugins, you could have a massive number of classes. > If you could describe the workflow necessary for implementing M:L:C, it > would help me out greatly. Does this help clarify? In response to your question about how using M:L:C would reduce security issues, there is obviously no way to prevent someone installing dangerous code, but by using M:L:C we close a few of the easiest vectors and make it so that bugs in a plugin are less likely to give an attacker complete access to the server. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
