The Joomla user is logged off upon return from Paypal

-- HikaShop version -- : 4.4.0
-- Joomla version -- : 3.9.23
-- PHP version -- : 7.3.25
-- Browser(s) name and version -- : Chrome 87.0.4280.88 and Edge
-- Error-message(debug-mod must be tuned on) -- : The Joomla user is logged off upon return from Paypal

I have four products defined in Hikashop, and php code that selects the appropriate the "add to cart" URL and places it into a payment request page. Clicking on the URL takes the user to Hiakshop. We have only one payment method defined, for Paypal.

Paypal is configured with an "auto return" set to lmphrf.org/index.php/paypal-payment-ok (which points to Lmphrf monohull » PaymentconfirmedForm).

This all works just fine except that, when the user is sent back to the paymentconfirmedform page he is no longer logged in to Joomla.

My php code tracks both the login username and the remote IP address, and uses either or both to record the successful payment. This work OK because I can track the IP address, but it is an inconvenience for the user in that he must re-login.

Thank you for your quick reply. Let me explain further, in a bit more detail.

To begin with, we use very little of the "power" of Hikashop. Our website's main purpose is to allow owners of large sailboats who wish to race those boats on several of the Great Lakes in the USA to obtain a handicap certificate for racing. Since all of the boats are different, much of the racing is done within a handicapping system. In order to properly handicap a boat we collect quite a bit of data about the boat, over 100 data items. The owner uses a custom built Joomla component called lmphrf monohull. He passes through twelve data entry pages and a summary page.

A button on the summary page directs him to a payment request page (within the lmphrf monohull component). The PHP code behind that page determines what type of handicap certificate is being requested and displays the "add to cart" Hikashop link for that product.

The Hikashop checkout page is then displayed. When the owner clicks the "finish" button, a checkout confirm page is displayed briefly while waiting for Paypal to assume control.

They then process their payment through paypal.

Coming back from paypal, a page is displayed for a very brief period of time. It is too quick for me to capture the page in a screen shot. And then they are passed to the lmphrf monohull payment confirmed page.

I have attached a series of screen shots of each of these pages, with the exception of the one that is displayed very briefly. They are numbered according to when they are displayed within the process flow.

If you look at the images in the Word document, you will see that the main menu contains seven items across the ribbon on all but the very last page. Some of these menu items only display because of the authorization level of the user. So, when the user is logged out, they disappear. There are only five menu items on the last image.

We really don't use any of the facilities of Hikashop to track a completed order. Instead, the PHP code behind the payment confirmed page attempts to locate the process that requested the payment and mark it paid. That code uses the login username as its first option. If the login is lost, then the fall back is to look at the remote IP address of the requestor. As you can see form the text on that page, the lmphrf monohull component is able to process the payment successfully. So my application is working.

However, it is concerning that the user loses his login. You asked about our session timeout possibly being the cause. I have that set at 120 minutes, and all of this processing takes place over a very short period of time, so that is not the issue.

Now, my guess is that the page that is displayed very briefly, and that I have been unable to capture, is really the lmphrf monohull component's checkout confirm page. I can tell you that, when that page flashes on the screen, it has the full compliment of menu items displayed. So the logout seems to occur between the time that page is displayed and when control is passed to the lmphrf monohull payment confirmed page.

This problem used to occur (when this application was built two years ago) occasionally when using the Safari browser. That is why I added logic to track the remote IP address. But now it is failing consistently under all browsers, Chrome and Edge in addition to Safari.

Thank you for the additional information.

My paypal payment plugin contains the following parameters:
URL: www.paypal.com/cgi-bin/webscr
Cancel URL: lmphrf.org/index.php/paypal-payment-failure
Return URL: lmphrf.org/index.php/paypal-payment-ok

paypal-payment-ok is an entry in my hidden menu and points to: Lmphrf monohull » PaymentconfirmedForm

I have a small MySQL table built into my application into which I log important events.

I inserted a bit of code temporarily into two of your files.

into Hikashop/controllers/checkout.php
I added the following code at the very beginning of public function after_end()
// start of dave wehnes mod
$tuser = JFactory::getUser();
$tquery = Jfactory::getDbo()->getQuery(true);
$tquery->insert('#__lmphrf_trace');
$tquery->set('type = "endfunc"');
$tquery->set('username = "' . $tuser->username . '"');
$tquery->set('name = "' . $tuser->name . '"');
$tracedb = Jfactory::getDbo()->setQuery($tquery);
$tracedb->query() ;
// end of dave wehnes mod

into Hikashop/views/checkout/tmpl/after_end.php
I added similar code

I then ran a test. Only the code in the controller/checkout.php function was executed. The code I inserted into the view did not.

The resulting trace entries look like this:
(The trace entries are displayed with the most recent one first)
(I record an entry in my payment request page and another in my payment confirmed page)

Trace-ID Timestamp Function Row-ID Username Name IP Address
8388 2021-01-05 14:30:38 payconfirmed 0 75.9.153.73
8387 endfunc
8386 2021-01-05 14:29:25 reqpayment 3588 dwehnes David Wehnes 75.9.153.73

The code I inserted into the Hikashop function only tried to capture the login username and name, not the other things I normally include. But it shows that I have lost the login user by the time that after_end function was executed.

So the problem exists before my payment confirmed page is loaded.

Also, I was able to take a quick screen shot of that "phantom" page that appears very briefly. I have attached it to this reply. I numbered it 4.5 since it appears between the 4 and 5 pages I provided with my earlier post. Anyway, it is the payment request page except that the URL at the top shows that of my payment confirmed page (and indicates that it is loading). Note that all menu items are displayed, indicating that the page was "painted" when my login was still valid.

I was busy with other things and did not have much time to devote to this. I turned debug on in the paypal plugin and ran another test.

I opened my site in a new tab while in paypal. I was still logged in. So I am not losing the login on the front side of the transaction.

I have attached the debug log. It doesn't provide me with any clues. maybe it will offer you some insight.

I will try to run additional tests with additional trace entries added to your code.

Dave

Hello,

I went in and inserted my trace code into three places within the Paypal plugin. (I added timestamp info to the trace code too.)

So now I have the trace code in five places:
1 in Hikashop/controllers/checkout.php at the after end function (tagged as aftendfunc)
2. in Hikashop/views/checkout/tmpl/after_end.php (tagged as afterend)
3. in the Paypal plugin function onBeforeOrderCreate (tagged onCreate)
4. in the Paylpal plugin function onAfterOrderConfirm (tagged onConfirm)
5. in the Paypal plugin function onPaymentNotification (tagged onPayment)

I ran two tests. The trace data is attached.

Yesterday, a series of trace entries were recorded that show a successful payment where the login ID was preserved.

I added trace entries to the payment plugin code.

I also updated my "normal" trace code to add platform and browser info to some trace entries.

The new trace is too large to include as a JPG file, so I copied it into Excel and then into a CSV file.

Dave

I went in and modified my trace code for the onCreate and onConfirm trace entries to include URL information.

I then ran a couple of tests. The first payment test ran through correctly. That is, my login within Joomla was preserved. The second test exhibited the problem, my login information was lost.

I have attached two partial screen shots of the trace data from these tests.

For the test in which the login was preserved, trace row 8757 shows me in the page that includes the link to the "add to cart" link. The next three trace entries are within Hikashop. Trace row 8761 shows me back within my application. My login information is displayed on all of these trace entries.

For the test in which the login information was lost, trace row ID 8766 shows me about to click on the add to cart URL. Row 8770 shows me back in my application. Between those two entries, three other trace entries are displayed, all within the Hikashop checkout process. It is within that series of trace entries that the login information is lost.

This indicates to me that the problem lies within Hikashop.

Now, it is very interesting to me that the trace points I thought I had active within the paypal payment plugin did not generate data during either of these tests, and I am not sure why. Those trace points appear to still be intact within the code.

Dave

OK, I forgot that I had commented out the trace code in the hikashoppayment.php file.

I ran another test this morning (the login ID was lost) and have provided the trace data as a CSV file.

Dave

I am confused. You just confirmed that the problem appears as Paypal is returning to Hikashop.

The payment method for Paypal is something that is provided by you - Hikashop. Am I correct?
The Paypal plugin is also provided by you - Hikashop.

This is not software I have written. It isn't part of the base Joomla product. It is all provided by Hikashop.

Are you telling me that you do not support the interface between Hikashop and Paypal? Why not? And how is a problem in that interface my problem, not yours?

Actually, you are mistaken.

The last time my application had control was about 20 trace entries earlier. The trace entry is identified with a function of "reqpayment" and has trade ID 8831.

From there, I invoke the URL for "Hikashop add to cart" that is part of the product definition with Hikashop. I have placed that Hikashop supplied URL into the request payment page as a clickable link. So, once a user clicks on that link, Hikashop is in control. You can see that in trace entries 8832 and 8833.

The login ID is lost in trace ID 8852. So there are 20 trace entries between when I hand control to Hikashop and when the login ID is lost.

Now, I have just made a change to the Joomla global configuration, changing the session manager from database to PHP. It is my understanding that PHP is a newer and better way to manage logins. I don't know if it will help.

Also, I wrote and implemented a plugin of my own yesterday to generate trace entries. It will trigger on "onUserAfterLogin" and "onUserLogoff". I am hoping that we'll see an entry when the login ID is lost. No guarantee though.

I haven't run any payment tests since. I am waiting for one to come in from a production user.

Dave

Here is an update.

The reason you suspected this was my problem was because I had specified a page of my own in the "force menu on checkout" field. I have set that to "none".

I have included a partial screen shot of the URL parameters within the Paypal payment method. Unfortunately, you cannot see the full URLs in the screen shot, so I have indicated them below:

Hikashop Cancel URL in Paypal payment method:
lmphrf.org/index.php/paypal-payment-failure

Hikashop Return URL in Paypal payment method:
lmphrf.org/index.php/paypal-payment-ok

I have included a partial screen shot of the auto return URL specified within my Paypal account. It points to the same URL as specified above within the payment method.

I changed the session handler in Joomla from "database" to "PHP". That did not have any effect.

I created my own plugin to track logins and logouts. My plugin is working fine for normal login and logoff activity. When the login is lost within the Hikashop process, my plugin does not get triggered.

I am now creating trace records (rows in a table of my own) for a variety of activities. Some of these are normal activities within the site. Some are from the entries I have inserted into the payment process.

I already mentioned logon and logoff.

I also create trace records in the page that includes the "add to cart" link to Hikashop. as well as my payment confirmed page. They show up in the trace as "reqpayment" and "payconfirmed".

Within Hikashop, I have inserted trace entries at:

Hikashop/Controllers/checkout.php
After_end function as entry "afterendfunc"

Plugins/Hikashoppayment/paypal/paypal.php
onBeforeOrderCreate as "oncreate"
onAfterOrderConfirm as "onconfirm"
onPaymentNotification as "onpayment"

plugins/system/hikashoppayment/hikashoppayment.php
onAfterInit as "onafterinit"
onAfterRoute as "onafterroute"

The login is lost on 1/3 to 1/2 of the payments processed.

I have included two traces. Within the traces, the ID column is the auto-increment primary key within the trace mysql table. The Row-ID column represents the ID of a row within a different table upon which my PHP code is operating. You can ignore it.

I have sorted the two traces in ascending order by ID, so the earliest trace entry is first.

Lost the logon info
trace file j3x_lmphrf_trace 2-11-21 1600.csv
Requested payment in trace id 13521
Process completed in trace id 13547

Logon info was not lost
trace file j3x_lmphrf_trace 2-11-21 1341.csv
Requested payment in trace id 12879
Process completed in trace id 12909

Since I set the "force menu on checkout" field to "none", my application pages are no longer involved in the payment process. All of the activity is within Hikashop and Paypal.

Note that my site has gotten busier. I am now averaging five payments per day in addition to other processes. You will note that, in the trace in which the login was not lost that there are a few trace entries associated with another logged on user.

Anyway, I hope this clarifies why I think the login is lost within the Hikashop/Paypal process and not elsewhere in my site.

Dave

Has anyone looked at the last set of trace data I sent?