Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Bug 38010 broke the vendors pages when Koha is running as a Mojolicious
application
This adds new routes to Koha::App::Intranet to mimic the Apache rewrite
rules added in bug 38010.
To be able to do that, the CGIBinKoha plugin's code had to be moved to a
controller. The logic remains the same.
Test plan:
1. Run `bin/intranet daemon -l http://*:3000/`
2. Point your browser to http://localhost:3000 (replace localhost by the
hostname/IP of koha's container, if needed)
3. Go to Acquisitions and search for a vendor. You should see the list
of vendors.
4. Click on "New vendor" button. Notice the URL changed to
.../acquisition/vendors/add.
5. Reload the page. You should still see the form to create a new vendor
6. Verify that you can create a vendor and that you are then redirected
to the list of vendors
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Koha::REST::V1::Auth checks the request URL path and do various things
depending on how it looks.
For instance, it allows everyone to access paths starting with
"/api/v1/oauth/"
But because of how Koha::REST::V1 was written, when using mojolicious
applications Koha::App::Intranet and Koha::App::Opac, paths had to add a
path prefix ("/api"), which means the final path as seen by
Koha::REST::V1::Auth looked like this: "/api/api/v1/oauth".
I said "had to", but actually there is another way that does not require
this path manipulation and that's what this patch does:
Koha::REST::V1 now accepts a configuration parameter that allows to
change the base path for API routes, which allows
Koha::App::Plugin::RESTV1 (used by Koha::App::Intranet and
Koha::App::Opac) to generate the right routes.
This configuration parameter defaults to "/api/v1", so when outside of
Koha::App::Intranet and Koha::App::Opac (when using
debian/templates/plack.psgi for instance), the behavior is unchanged.
Test plan:
1. Do not apply the patch yet
2. Run `bin/intranet daemon -l http://*:8080`
3. Run `curl -i -d{} http://127.0.0.1:8080/api/v1/oauth/token`
It should return a 403 error, with an error message "Authentication
failure".
4. Stop `bin/intranet daemon -l http://*:8080` by hitting Ctrl-C on the
terminal you started it
5. Apply the patch
6. Run `bin/intranet daemon -l http://*:8080` again
7. Run `curl -i -d{} http://127.0.0.1:8080/api/v1/oauth/token`
This time it should return a 400 error with an error message saying
the "grant_type" property is missing.
This error is normal as we did not send any data in the POST request
body, and seeing this means Koha allowed us to use that route because
it recognized '/api/v1/oauth/' at the start of the URL path
8. You can do the same test with `bin/opac`
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised. See Bugzilla for notes from testing.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The REST API can return translated strings to the opac or staff
interface, so it should respect the KohaOpacLanguage cookie and return
translations in the same language than the interface.
Test plan:
1. Do not apply patch yet
2. Log in to koha staff interface
3. Use the browser's devtools to get the value of CGISESSID cookie
4. Make sure you have at least 2 languages installed ('en' + another
one - I'll use 'fr-FR' as an example in this test plan)
5. Find an item and note its itemnumber and itemtype
6. Go translate this itemtype's description (admin » item types » edit
item type » translate). Add a translation for 'en' and another one
for your language.
7. Close your browser tab (do not logout) and restart Koha to flush the
memory cache.
8. Execute the following commands (replace variables by the correct
value):
curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
-H 'x-koha-embed: +strings' \
-H "Cookie: KohaOpacLanguage=en; CGISESSID=$CGISESSID" \
| jq -r '._strings.item_type_id.str'
If you do not have jq, it can be found in most distributions
packages. Or you could inspect the JSON manually at the path
/_strings/item_type_id/str
Restart Koha again, and execute the same command but with your
language set in KohaOpacLanguage cookie:
curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \
-H 'x-koha-embed: +strings' \
-H "Cookie: KohaOpacLanguage=fr-FR; CGISESSID=$CGISESSID" \
| jq -r '._strings.item_type_id.str'
Depending on how Koha sort the languages (not sure how it's done),
you should get either the 'en' one or the 'fr-FR' one, but the
important thing is you should get the same translation, no matter
what the value of KohaOpacLanguage is, which is the issue this patch
is trying to fix.
9. Apply the patch and restart Koha
10. Repeat step 8. This time you should get the translation
corresponding to the language set in KohaOpacLanguage cookie
Side note:
* The need to restart Koha before each request is due to a bug (see bug
38454). If already pushed when you're testing this one, you don't have
to restart.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1. Run bin/opac daemon -l http://*:3001/
2. Go to http://localhost:3001/cgi-bin/koha/opac-user.pl
3. With browser devtools, locate csrf_token hidden input within the
login form and remove it or modify it
4. Try to submit the form with correct credentials, it should fail
("Wrong CSRF token")
5. Reload the page, try to log in normally without modifying the DOM, it
should succeed
6. Run bin/intranet daemon -l http://*:3002/
7. Go to http://localhost:3002/cgi-bin/koha/mainpage.pl
8. With browser devtools, locate csrf_token hidden input within the
login form and remove it or modify it
9. Try to submit the form with correct credentials, it should fail
("Wrong CSRF token")
10. Reload the page, try to log in normally without modifying the DOM,
it should succeed
11. Run prove t/db_dependent/mojo/csrf.t
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This was a workaround I wrote when Koha::Caches->flush_L1_caches was not
flushing all caches correctly. Now it's not needed and it causes
problems, so it must be removed.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is a proof-of-concept of Koha as a Mojolicious application
This has several benefits:
- Development setup is easier. No need for apache or nginx. Just run
`morbo bin/intranet` or `morbo bin/opac` and go to
http://localhost:3000 (URL rewrites and static files are handled by
the app)
- apache2/nginx configuration is simpler too (an example of nginx
configuration is included in the patch)
- starman and plack middlewares can still be used for debug or gzip
compression for instance (see app.psgi)
- Using Test::Mojo we can test the whole application, as we do with the
REST API (which is a Mojolicious application too)
- It opens a way for converting CGI scripts into Mojolicious
controllers and actions (even if that's not possible at the moment
because of the authentication code)
It uses the same mechanism as Plack::App::CGIBin to deal with CGI
scripts, so it should be equivalent in terms of performance
How to test ?
- Run `morbo bin/intranet`, then go to http://localhost:3000/ and try to
find bugs. Check the REST API at http://localhost:3000/api/v1
- Run `morbo bin/opac`, then go to http://localhost:3000/ and try to
find bugs. Check the REST API at http://localhost:3000/api/v1
- Run `starman -l :5000 -l :5001` and verify that intranet
(http://localhost:5000) and opac (http://localhost:5001) work normally
- Read the code (and the comments), it's not very long
Signed-off-by: Jerome Charaoui <jcharaoui@cmaisonneuve.qc.ca>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Tomas Cohen Arazi
Julian Maurice
Koha Development Team
Martin Renvoize