Bug 23761 - Allow PayPal return url to be set based on current domain, not OPACBaseURL
Summary: Allow PayPal return url to be set based on current domain, not OPACBaseURL
Status: RESOLVED DUPLICATE of bug 21701
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low minor (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-07 10:29 UTC by Kyle M Hall
Modified: 2019-10-07 13:21 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 23761 - Allow PayPal return url to be set based on current domain, not OPACBaseURL (1.98 KB, patch)
2019-10-07 10:32 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 23761 - Allow PayPal return url to be set based on current domain, not OPACBaseURL (2.08 KB, patch)
2019-10-07 10:34 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2019-10-07 10:29:07 UTC
In some library systems, each library has a customized sub-opac and a separate PayPal account. This is accomplished using the css and syspref override directives in the Apache conf. This all works great until a patron wants to make a PayPal payment.

Let us assume OPACBaseURL is set to catalog.mylib.org, the generic unstyled OPAC. Each library then has a 'sub-opac' such as labA.catalog.mylib.lorg. If the patron is on an OPAC at libA.catalog.mylib.org, and makes a paypal payment, the patron will not be returned to libA.catalog.mylib.org. Instead, the patron will be send back to catalog.mylib.org.

The simple solution is to use the CGI module to build a URL using the current base URL: $cgi->url( -base => 1 )
Comment 1 Kyle M Hall 2019-10-07 10:32:34 UTC
Created attachment 93817 [details] [review]
Bug 23761 - Allow PayPal return url to be set based on current domain, not OPACBaseURL

In some library systems, each library has a customized sub-opac and a separate PayPal account. This is accomplished using the css and syspref override directives in the Apache conf. This all works great until a patron wants to make a PayPal payment.

Let us assume OPACBaseURL is set to catalog.mylib.org, the generic unstyled OPAC. Each library then has a 'sub-opac' such as labA.catalog.mylib.lorg. If the patron is on an OPAC at libA.catalog.mylib.org, and makes a paypal payment, the patron will not be returned to libA.catalog.mylib.org. Instead, the patron will be send back to catalog.mylib.org.

The simple solution is to use the CGI module to build a URL using the current base URL: $cgi->url( -base => 1 )

Test Plan:
1) Set up sub-OPACs and PayPal ( production or sandbox mode )
2) Initiate a payment from a sub-OPAC
3) Note you are returned to whatever is in OPACBaseURL
4) Apply this patch
5) Restart all the things!
6) Initiate a second payment from a sub-OPAC
7) Note that you are returned to the correct sub-OPAC url!
Comment 2 Kyle M Hall 2019-10-07 10:34:51 UTC
Created attachment 93818 [details] [review]
Bug 23761 - Allow PayPal return url to be set based on current domain, not OPACBaseURL

In some library systems, each library has a customized sub-opac and a separate PayPal account. This is accomplished using the css and syspref override directives in the Apache conf. This all works great until a patron wants to make a PayPal payment.

Let us assume OPACBaseURL is set to catalog.mylib.org, the generic unstyled OPAC. Each library then has a 'sub-opac' such as labA.catalog.mylib.lorg. If the patron is on an OPAC at libA.catalog.mylib.org, and makes a paypal payment, the patron will not be returned to libA.catalog.mylib.org. Instead, the patron will be send back to catalog.mylib.org.

The simple solution is to use the CGI module to build a URL using the current base URL: $cgi->url( -base => 1 )

Test Plan:
1) Set up sub-OPACs and PayPal ( production or sandbox mode )
2) Initiate a payment from a sub-OPAC
3) Note you are returned to whatever is in OPACBaseURL
4) Apply this patch
5) Restart all the things!
6) Initiate a second payment from a sub-OPAC
7) Note that you are returned to the correct sub-OPAC url!

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: David Kuhn <kuhn@monterey.org>
Comment 3 Katrin Fischer 2019-10-07 12:41:17 UTC
Hi Kyle, could you please take a look at how bug 21701 might relate to this? We just got it signed off at the hackfest last week.
Comment 4 Kyle M Hall 2019-10-07 13:04:14 UTC
(In reply to Katrin Fischer from comment #3)
> Hi Kyle, could you please take a look at how bug 21701 might relate to this?
> We just got it signed off at the hackfest last week.

That solves the same problem, albeit in a different way. I'll close my bug and QA that one :)

*** This bug has been marked as a duplicate of bug 21701 ***
Comment 5 Katrin Fischer 2019-10-07 13:21:43 UTC
(In reply to Kyle M Hall from comment #4)
> (In reply to Katrin Fischer from comment #3)
> > Hi Kyle, could you please take a look at how bug 21701 might relate to this?
> > We just got it signed off at the hackfest last week.
> 
> That solves the same problem, albeit in a different way. I'll close my bug
> and QA that one :)
> 
> *** This bug has been marked as a duplicate of bug 21701 ***

Cool - thx!