| Summary: | opac/opac-account-pay-return.pl should not require CSRF | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
| Component: | OPAC | Assignee: | Owen Leonard <oleonard> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | dcook |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Nick Clemens (kidclamp)
2025-11-05 20:57:30 UTC
Can you run us through how this should work? I see a reference to opac-account-pay-return.pl in "opac_online_payment_begin.tt" in dev-koha-plugin-kitchen-sink, but it looks like it is an update so it should have a CSRF token (although it's missing in the plugin version I'm looking at). (In reply to David Cook from comment #1) > Can you run us through how this should work? > > I see a reference to opac-account-pay-return.pl in > "opac_online_payment_begin.tt" in dev-koha-plugin-kitchen-sink, but it looks > like it is an update so it should have a CSRF token (although it's missing > in the plugin version I'm looking at). So the general process is: 1 -opac payment begin - We select the charges to pay - the user/charges are then sent to the vendor site for processing payment 2 -the vendor should then POST to the API to make the actual payment and verify things on their end 3 - opac payment end - the payment vendor redirects the patron back to the Koha catalog, they may send some information about the payment, but the actual changes have been handled in step 2, step 3 is just reporting |