Open kivilahtio opened 5 days ago
Regarding using the REST API and 303 redirect...
I managed to actually get the plugin working by implementing the CSRF-changes. And using the demo mode I see how it works. It has a lot of UI and record matching and is all-in-all quite impressively featureful.
Koha::Plugin::VendorAcquisition::Order is created when the order-payload is sent from AdLibris. So it would be possible to use the REST API to create the initial Koha::Plugin::VendorAcquisition::Order -object. Then redirect to the receive.tt -template using a GET-request from the 303-redirect. https://www.rfc-editor.org/rfc/rfc7231#section-6.4.4
CSRF update PR: https://github.com/Kreablo/koha-plugin-vendor-acquisition/pull/4
Hi! Thank you for sharing this great plugin. I am testing it for Koha 24.05.3 and I am having a problem submitting the plugin configuration form, thanks to the way Koha now handles CSRF-tokens.
Here is my implementation of a CSRF-plugin capability. https://github.com/Hypernova-Oy/koha-plugin-self-service/commit/75926ddf0d4638acdf58fc6e7759c51b37c5913c
In the latest plugin version the CSRF-token generated is not a valid token for the Koha's underlying core authorization flow, as the CSRF validity is now checked outside the scope of the plugin.
CSRF-token is intended to be a request-specific verification that the user's browser is not doing anything malicious without the user's consent. In some cases the CSRF-token can be session-specific. In this plugin's context, the CSRF-token is set once for the whole lifetime of the plugin. This defeats the purpose of a CSRF-token. I understand that this might be necessary for the workflow AdLibris integration needs.
However using the Koha REST API, no CSRF token is needed. And afaik should never be required. Koha plugin can introduce an exact same schema for the 'vendor_order_receive'-endpoint, so the change can be backwards compatible, by only changing the endpoint path to a REST API contrib-path.
By changing the configure-endpoint to use the Koha::Token->new->generate_csrf() -pattern we could improve the security posture. And by changing the 'vendor_order_receive'-endpoint to a REST API endpoint, we can improve the integration maintainability with AdLibris et. al. We could add a "HTTP 303 See Other"-redirect to send the user to the Koha's Acquisition page with the new order details straight from the REST API response. This is not very RESTy, but could work nicely in making the AdLibris integration easy.