[Koha-bugs] [Bug 7804] Add Koha Plugin System

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7804

--- Comment #27 from Jared Camins-Esakov <jcamins at cpbibliography.com> ---
(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.