The Joomla user is logged off upon return from Paypal

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #327903

-- 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.

Please Log in or Create an account to join the conversation.

  • Posts: 81363
  • Thank you received: 13037
  • MODERATOR
3 years 2 months ago #327914

Hi,

The only case when HikaShop logout the customer is if the product has the "user group after purchase" setting configured in order to add a user group to the user after the purchase of a product. However, that option is only available with the Business edition and I can see that you have the Essential edition. So it shouldn't be linked to this.

Note that normally, there is no need to track anything. Besides the return of the user to your website, there is a payment notification request sent directly from PayPal's server to your website to tell it that the payment was done for the order, and HikaShop will then automatically change the status of the order from created to confirmed.
The "return URL" parameter in the payment method is there only for you to display a different thank you page to the customer.
If the order is not confirmed automatically, you have a problem. We actually have some documentation about this problem here:
www.hikashop.com/support/documentation/i...or.html#notification
So I would recommend checking it.

Note also that a user will be automatically logged off if his user session expires based on the session lifetime configured in your Joomla configuration. So if you have a low value there, it's possible that the session expires while the user is paying on PayPal.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #327939

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.

Please Log in or Create an account to join the conversation.

  • Posts: 81363
  • Thank you received: 13037
  • MODERATOR
3 years 2 months ago #327951

Hi,

When the PayPal plugin sends you to the PayPal payment page, it gives to PayPal the "after_end" generic URL of HikaShop so that PayPal will redirect back to that URL after the payment.
On that URL, HikaShop will clear the cart from the user session and then check the "return URL" setting of the payment method used for the order.
If something has been entered in that setting, it will redirect to that URL.
If there is nothing in that setting, it will display the checkout / after_end view file of HikaShop which is the default "thank you" page of HikaShop.
You say that there is a page that displays briefly when you're being redirected back to the website. So it's likely that it is that default thank you page which is displaying, and that you've customized that view file via the menu Display>Views of the backend of HikaShop to do your own redirect to the lmphrf monohull payment confirmed page.
If you see all your menus in that default thank you page, it's likely that the problem happens on your lmphrf monohull payment confirmed page and thus it will be hard to help you as we don't know its code.
I would still recommend to check the checkout / after_end view file to confirm that it is what is going and that there is no code in there which could log out the user.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #327978

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.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 81363
  • Thank you received: 13037
  • MODERATOR
3 years 2 months ago #327993

Hi,

It's normal that the code in the after_end view file is not run since you have a return URL in your payment method and thus the code in the after_end function of the controller will redirect to that return URL before trying to display the after_end view.
Before the after_end function of the controller, there is not much code (it's just generic routing code). So it's likely that you've already be logged out before you come back from paypal.
So I would recommend to do such a test:
- do a checkout and get redirected to PayPal
- before validating the payment on PayPal's side, open your website on a new tab to see if you're still logged in or not.
- it's probable that it won't be the case, which indicates that the logout happens just before the redirection to PayPal. So then I would add debug code in the different steps (near the end) of the "confirm" function of the checkout controller to check when the login is lost. At the end of that confirm function, the checkout / end.php view file is displayed which outputs the redirection form to PayPal.
- If you're still logged in when you arrive in PayPal, but you get logged out when you arrive on the after_end, then it's probable that the logout happens with the payment notification request which is sent by PayPal to your server after the payment. This request is processed by the onPaymentNotification function of the plugins/hikashoppayment/paypal/paypal.php file and if you activate the "debug" setting of the paypal payment method, that function will output debug information in the "payment log file" you can find in the HikaShop configuration.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328034

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

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328054

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.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 81363
  • Thank you received: 13037
  • MODERATOR
3 years 2 months ago #328046

Hi,

The information in the log indicates that you indeed receive the payment notification from PayPal after the payment and that the PayPal plugin automatically changes the status of the order from "created" to "confirmed" at that point.
So it's possible that you have something acting on that change which leads to the user being logged out.
For example, in a custom plugin, you could have implemented the onAfterOrderUpdate trigger to clear the information of the user session in the database, which would lead to the user being logged out when coming back on the website. But if that was the case, I suppose you would already know it...
To rule that out, since apparently you don't need HikaShop to update the payment notification, you could turn off the "allow payment notification from paypal" setting of your PayPal payment method and do another test.
If you still have the issue even though that option is turned off, then you can rule out that it comes from the payment notification process.
But in that case, I don't see why the user session would be lost when you come back from PayPal. As I said, before arriving to the after_end function of the checkout controller there is almost nothing:
- the initialization of Joomla
- the routing of the URL to HikaShop
- the initialization of HikaShop
- the call to the checkout controller
- the call to the after_end function
I don't see any reason why these would logout the user.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328135

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



And here is a set of entries from a test I ran where the ID was lost.



The problem is clearly within the realm of Hikashop and its paypal payment plugin.

How can we get this resolved?

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 81363
  • Thank you received: 13037
  • MODERATOR
3 years 2 months ago #328142

Hi,

Well, your log actually shows the opposite.
In the traces for when the id was lost, you can see that the id is lost between the onConfirm (which is when HikaShop redirects the redirection to PayPal), and the "afterendfunc" (which is when the customer comes back to HikaShop after the payment).
What we learn is that the payment notification happens after that and thus is not linked to the problem either.

The issue here is that we still don't even know how and where the user is getting logged out. So that's the first step.
What I would recommend is to add a trace in a plugin of the group "system" in the "onAfterInitialize" and "onAfterRoute" functions if the parameters of the URL correspond to the after_end URL. That way, you'll be able to see if the user is already logged out or not after Joomla is initiliatized and after the routing of the after_end URL.
If the user is already logged out after the initialize of Joomla, one cause I can think off would be that the user session is lost when the customer is redirected back because of the way the user session is handled by your PHP. For example, if the user session is different between the www.mywebsite.com and mywebsite.com URL, if you are redirected to PayPal from the first URL and you come back to the second URL, then you would be logged out because another user session is initialized by PHP.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328178

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

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328254

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

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328299

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

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 4486
  • Thank you received: 609
  • MODERATOR
3 years 2 months ago #328398

Hello,

We are sorry but your last attached file clearly shows that your client was logged out even before Hikashop was loaded, see my screenshot to better understand my point :



You can see to that the customer is logged until the last hikashop operation in the Checkout process.
From this, unfortunately we can only tell you that the problem lies between the return of Paypal and the actual arrival on the resumption of hikashop process.

We hope that you will be able to find the root issue.
Regards

Last edit: 3 years 2 months ago by Philip.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328536

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?

Please Log in or Create an account to join the conversation.

  • Posts: 25994
  • Thank you received: 4004
  • MODERATOR
3 years 2 months ago #328543

Hello,

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

No, you misunderstood the analysis.
When the user come back to your Joomla website (Joomla and not HikaShop ; which is not loaded yet) ; there is no User details.

The Paypal plugin redirect the user to the Paypal website ; but what is happening in the Paypal website is not related to the Paypal plugin.

Joomla is an eco-system where you can have plenty components/plugins working in the same time.
You can have a plugin which refuse the cookies if the "referer" is not your website (to protected against phishing or else).

Please understand that, if the user is not seen as connected (no session) when Joomla made its initialisation ; HikaShop can't retrieve the session which is not there and not loaded.

The last HikaShop action in the checkout ; the user is still logged.
The moment HikaShop is loaded when the user "come back" ; there is no more session.

That is the current situation.

Regards,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 2 months ago #328689

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

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 1 month ago #329555

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

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 14
  • Thank you received: 0
  • Hikashop Essential
3 years 3 weeks ago #330206

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

Please Log in or Create an account to join the conversation.

Time to create page: 0.093 seconds
Powered by Kunena Forum