Test plan:
1. Introduce a typo in swagger.json or another spec json file.
2. Restart plack if used or try to access the REST APIs
3. Without the patch, verify that an incomplete error message and potentially lots of stack trace are logged.
4. With the patch, verify that much more meaningful error messages are logged and stack trace is omitted.
5. Fix the problem introduced in step 1 and verify that no messages are logged, or only warning about bundle is logged with Debian Stretch.
6. Repeat with a REST API plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
rel_file returns the path anyway
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
By default, JSON::Validator::OpenAPI tries to fetch the
swagger v2 schema from http://swagger.io/v2/schema.json.
If you've installed from CPAN, JSON::Validator::OpenAPI will
come with a cached copy, so it won't try to fetch it over HTTP.
However, if you've installed from libjson-validator-perl
from Debian/Ubuntu, the Debian package excludes the cached copy,
so JSON::Validator::OpenAPI tries to fetch it over HTTP.
Unfortunately, today and other days in the past, the file at
http://swagger.io/v2/schema.json has been unavailable, and this causes
Koha to crash in a perpetual loop.
This patch includes a copy of the swagger v2 schema, and it loads
it locally rather than fetching over HTTP.
The changes to Koha/REST/Plugin/PluginRoutes.pm are not required,
since the validator isn't currently called there, but I've added
a patch to future proof it.
To Test:
0a) Remove /usr/share/perl5/JSON/Validator/cache/36d1bd12eeed51e86c8695bd8876a9df
if it exists
0b) Block external access to http://swagger.io/v2/schema.json or
test during an outage when it's unavailable
0c) Do not apply patch
1) koha-plack --restart kohadev
2) Note that it crashes in a loop and is unavailable in web browser
3) Apply patch
4) koha-plack --restart kohadev
5) Note that Koha comes up and there are no errors in the Plack logs
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This follow-up patch moves the check outside the register routine. The
Mojo plugin won't be loaded unless there's no need to install.
As the original tests rely on V1.pm to be able to load the plugin, they
are still valid, and they should still pass as there's no behaviour
change.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a check on Koha being actually installed to the
PluginRoutes Mojolicious plugin.
If Koha is not installed, plugin routes won't be tried to get installed.
This has the effect of making the webinstaller functional again (when
enable_plugins is set to 1).
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Reset your working branch
6. Delete your database (e.g. in koha-testing-docker):
$ mysql -hdb -ppassword
> DROP DATABASE koha_kohadev;
> CREATE DATABASE koha_kohadev; \q
7. Set enable_plugins to 1 in koha-conf.xml
8. Restart all:
$ service memcached restart
$ koha-plack --restart kohadev
9. Open the staff interface
=> FAIL: Hangs, the logs show nasty errors (koha-plack-err)
10. Apply this patches
11. Restart all
12. Repeat 10
=> SUCCESS: The web installer shows up :-D
13. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch changes the spec loading so that it is fully loaded and merged with any plugin routes before validation. The individual parts are separately validated only if the resulting complete spec is invalid. Note: the OpenAPI plugin validates the spec given to it, so normally no manual validation is necessary.
Test plan:
1. prove -v t/db_dependent/Koha/REST/*
2. prove -v t/db_dependent/api/v1/*
Sponsored-by: The National Library of Finland
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Owen Leonard 2018-03-16 10:47:47 UTC :
<<
I don't think the system preference adds any security. There are already multiple permissions required for working with plugins:
- Configure plugins
- Manage plugins ( install / uninstall )
- Use report plugins
- Use tool plugins
And even with those permissions your server must be configured to allow the use of plugins.
>>
Test plan :
1) Install kitchen sink plugin https://github.com/bywatersolutions/koha-plugin-kitchen-sink
2) Run misc/devel/install_plugins.pl
3) Set config enable_plugins=1
4) Check all parts of the plugin are working
5) Set config enable_plugins=0
6) Check all parts of the plugin are disabled
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch serves static files declared within plugins.
To declare static files the plugin must implement the method 'static_routes' which retrieves the spec of static file routes to add to the API.
Once those routes are added to the API, the become available through the /api/v1/contrib/<api_namespace>/static/<path>/<to>/<file>/<filename> endpoint.
To test:
1) Install bug-22835-plugin.kpz
2) Point your browser to /api/v1/contrib/kitchensink/static/static_files/mm.gif
CHECK => No file is served
3) Apply this patch
4) restart_all
5) Repeat step 2.
SUCCESS => File is served!
6) Sign off
Sponsored-by: Theke Solutions
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This causes test failures in D8 and would require packaging our own perlcritic
Reverting until future date when consequences do not outweigh benefits
This reverts commit ecc94da6b2.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Check all Koha/REST files and confirm that 'use Modern::Perl;' has
been removed.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds plugins the capability of injecting new routes on the
API.
The plugins should provide the following methods to be considered valid API-generating plugins:
- 'api_routes': returning the 'path' component of the OpenAPI specification corresponding to the routes served by the plugin
- 'api_namespace': it should return a namespace to be used for grouping the endpoints provided by the plugin
otherwise, they will be just skipped.
All plugin-generated routes will be added the 'contrib' namespace, and
will end up placed inside /contrib/<namespace>, where <namespace> is what the 'api_namespace' returns.
A sample endpoint will be added to the Kitchen Sink plugin, and tests
are being written.
To test:
- Apply this patches
- Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> SUCCESS: Tests pass!
- Install the (latest) KitchenSink plugin
- Point your browser to the API like this:
http://koha-intra.myDNSname.org:8081/api/v1/.html
=> SUCCESS: The /contrib/kitchensink/patrons/:patron_id/bother endpoint
implemented by the plugin has been merged!
- Sign off! :-D
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@deichman.no>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>