Bug 41197 - opac/opac-account-pay-return.pl should not require CSRF
Summary: opac/opac-account-pay-return.pl should not require CSRF
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-05 20:57 UTC by Nick Clemens (kidclamp)
Modified: 2025-12-01 12:46 UTC (History)
1 user (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2025-11-05 20:57:30 UTC
This page is intended for redirect/return from external payment vendors - they are not going to have/get a CSRF token from Koha for this.

The payments are handled in a POST to the API, so this should not be a sensitive page, it just provides user confirmation.

Some vendors use only a POST, we should not require CSRF on this page.
Comment 1 David Cook 2025-11-05 22:51:38 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).
Comment 2 Nick Clemens (kidclamp) 2025-12-01 12:46:30 UTC
(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