Jump to content

Big problem after upgrade to 5.2.7 - Paypal Plugin not working


CBGitty

Recommended Posts

Today I upgraded my CC install from 5.1.5 to 5.2.7. I had thought I had fully tested the new version in a development install, and verified that PayPal checkout was working. I only have the PayPal plugin enabled, not the gateway.

 

However I have discovered that payments via the paypal account are not working (Credit card payments are). The issue seems to be that when PayPal passes back to my site, the user is presented with a checkout screen where they are asked to log in or enter their billing information - even though they were logged in before being transferred to Paypal.

 

I have not changed any of the IPN settings in the CC store setup, or in PayPal. Here is what the URL on return from PayPal looks like:

 

https://www.cbgitty.com/cubecart/index.php?_a=confirm&token=EC-6H5522029F332650H&PayerID=F88FKST7G3V7J

 

This is a very serious issue since a large number of my customers use their paypal accounts. As a short-term bandaid I have disabled the paypal plugin and re-enabled the old paypal gateway and card capture gateways, just to keep orders coming in.

 

I need some help with what the proper settings are for the PayPal plugin in CC, as well as how PayPal itself should be configured. Also has anyone else run into this?

Link to comment
Share on other sites

I changed the mail method, no result. When the customer is returned from PayPal, they are no longer logged in. Should I file an actual helpdesk ticket for this? I need it sorted out as quickly as possible and if I have to pay for that so be it.

Link to comment
Share on other sites

It may be a red herring, but I noticed that in the return URL, after _a=confirm it has "&" before token= instead of just an ampersand. IN my error_log, I see this:

 

[27-Jan-2014 12:45:35 UTC] PHP Warning:  Security Warning: Illegal array key "amp;token" was detected and was removed. in /home/cbgitty/public_html/cubecartdev/classes/sanitize.class.php on line 88

 

So if it is unsetting that key maybe it is losing the key info being returned from PayPal, which is causing it to wipe out the user's login? Just a guess. 

Link to comment
Share on other sites

That & in the URL is definitely part of the problem. I added some code temporarily to the sanitize class that fixes it so that the token value gets properly passed, and with that set I was able to complete the order. The user is still not logged in when returned from PayPal (which still seems like a problem), but their info was filled in correctly and mashing the complete button a couple of more times did cause the payment to be processed and the order to go to Processing. 

 

So the questions at this point are:

1) Why is the user session ended when returned from PayPal? 

2) What could be causing the return URL to be malformed? Here is what the full return URL looks like. AS you can see the ampersand after token is OK:

 

https://www.cbgitty.com/cubecartdev/index.php?_a=confirm&token=EC-2EW66691MJ2197540&PayerID=F88FKST7G3V7J

Link to comment
Share on other sites

This is odd. I think the code in question is in modules/plugins/PayPal_Pro/hooks/class.cubecart.construct.confirm.php

httpredir('index.php?_a=confirm&token='.$_GET['token'].'&PayerID='.$_GET['PayerID']);

But.. it's not malformed. To answer your questions:

 

1. From testing on my dev store it doesn't finish the session it just empties the basket.

2. I'm not sure yet.


I don't know if ini.inc.php is to blame.. 

ini_set('arg_separator.output', '&');	// Set argument separator from & to & for XHTML validity
Link to comment
Share on other sites

The following is what I had to add to functions.inc.php, httpredir():

    ## Now we'll send the redirect header using one method or another
    $destination    = preg_replace('#([^:])/{2,}#', '$1/', urldecode($destination));
    $destination    = str_replace('amp;', '', html_entity_decode($destination, ENT_COMPAT, 'UTF-8'));
    $destination    = filter_var($destination, FILTER_UNSAFE_RAW);

I have narrowed down where the corruption occurs to this statement:

$rewrite = $GLOBALS['seo']->rewriteUrls(sprintf('href="%s"', $destination));

 

Within reWriteUrls(), generatePath() and queryString() are called. queryString() -- used for multiple purposes, thus is not recommended to change -- uses PHP's http_build_query(), in turn uses the php.ini value for arg_separator.output.

 

CubeCart explicitly sets this in ini.inc.php:

ini_set('arg_separator.output', '&');    // Set argument separator from & to & for XHTML validity

 

A bit more discussion is >here.

Link to comment
Share on other sites

bsmither - adding those lines to functions.inc.php did seem to clear up the & issue in the return URL. So at this point I am sometimes able to complete an order normally. Other times seemingly random results occur, from blank screens to PayPal saying it's an invalid transaction, to having to step back through portions of the checkout process. At persent the results are far too random and confusing to put in front of customers. I am working on trying to trace the causes of the different results.

 

In the meantime the paypal gateway is working and the biggest immediate pain is the old card_capture gateway, because I have to manually process every CC order. Ain't nobody got time for that. I am leaning towards trying to coddle together a combination of the old PayPal gateway and the paypal plugin, wherein the plugin would only display the credit card option and the express checkout/paypal pro button/selector would be hidden. The goal would be to have the old paypal gateway used for PayPal payments and the plugin automatically handle credit card payments.

Link to comment
Share on other sites

Well, the kludge is in and seems to be working. Though it pained me to have to implement something so kludgey, it should take some of the pressure off in terms of moving towards a solution with the PayPal payments. On a positive note, between bsmither's 2 line addition to functions.inc.php and my addition to the sanitize class, the Amazon payments plugin is now working. So overall an optimist would call this upgrade a net gain, if he were able to ignore the 8+ hours he's spent on this so far.

Link to comment
Share on other sites

So I suppose the question here is why this issue affects this store and not others. I can't reproduce this on my development store at all and we have had no other reports if this in the forums or help desk. PayPal is by a long shot the most popular payment method.

I'm sorry to come across defensive and I'm also truly sorry you have had a rough time here. I'll have a deeper look into this tomorrow.

It would be interesting to privately see you PHP Info output.

Link to comment
Share on other sites

Another thing in PayPal_Pro I would ask that you try (saves needing to disable a part of the sanitizer class) is this:

 

Plug-in PayPal_Pro/website_payments_pro.class.php, near line 255:

currently:  'NOTIFYURL'     => $GLOBALS['storeURL'].'/index.php?_g=rm&type=gateway&cmd=call&module=PayPal'
try this: 'NOTIFYURL'     => $GLOBALS['storeURL'].'/index.php?_g=rm&type=gateway&cmd=call&module=PayPal'

I don't have any PayPal API documentation, thus the required use of the encoded ampersand is not settled in my mind. So this may or may not solve any remaining glitches.

Link to comment
Share on other sites

Sorry Al I know how hard these things can be to track down. In a past life I was a software developer and also worked on the support side so I know how two-sided the "it's working on my end" argument can be. This install of cubecart has been up and running for 4 or so years, since version 3-point-something, and in that time it has handled over $1.5 million in sales, so considering what I paid for it I can't complain too much. I just get frustrated when it seems like every time I attempt to upgrade to the latest and greatest, significant new problems crop up. But I realize that it almost certainly is something specific to my environment and I would gladly work with you to get it sorted out, and I will pay for support credits/time to cover it if need be. The paypal checkout process via the paypal plugin has been causing my customers grief for some time and getting that nailed down and rock solid would really be great. I can certainly send you the phpinfo() output, or give you admin access to the development testbed site, ftp access, phpadmin access, whatever is needed.

 

In other news, I did try switching to one of the default themes (kurouto red) on the off chance that the cintoxblue theme I've been running had an issue, but it didn't seem to have any effect.

 

Also: bsmither, I didn't disable any parts of the sanitize class, I just added a line to remove "amp;" from incoming $key via str_replace() around line 86 in the _clean function, before the other sanitizing checks.

Link to comment
Share on other sites

If the URL is coming in with & in it, then something is sending it out that way.

 

I read somewhere on the PHP docs site that such-n-such a function already encodes ampersands, so having your application do it would be a mistake. I don't remember what that function was. I'll try to find it.

 

OR, someplace in the Merchant Account control panel at PayPal may have that string in an IPN setting somewhere.

Link to comment
Share on other sites

Ok so there are a number of issues here;

 

1. The & in the URL

- I haven't got around to this yet but will come back to it. 

 

2. Dropped basket data on return to CubeCart.

- This is indeed because IE change the user agent since recent IE 11 releases. As per usual MS make their own rules. :P So Brian was correct. Microsoft advise dropping user agent checking in place for browser feature checking. This is fine but such features can be detected with PHP without some cr@ppy ajaxy client side code using something like Modernizr. Rubbish. Anyhow we have no choice but to drop agent checking for IE. I'll post an update shortly. 

Link to comment
Share on other sites

@ToucanWebDesign - Hmm there may well be I'll have a look into that shortly. 

 

Issue #2 Problem:

I have been able to reproduce this issue in IE11. Basically since a very recent release of IE11 the user agent does change on return to an already visited site from another. So I discovered that if you get to PayPal then click the "Cancel" link which takes you back to the store the user agent changes. This in turn makes CubeCart think the session has been hijacked and it is destroyed. Now to start with I though we could get around this by looking out for "r:11" in the user agent code for IE11 but to my shock sometimes on return from PayPal the user agent dropped down to IE10?! 

 

Issue #2 Microsoft Suggested Solution:

They suggest that browser security detection is all done by checking the browser enabled features. This at first seems like a good solution until you realise that its impossible for this to be done server side without some horrible fudgy AJAX call on each page load. No.. thats not a solution I don't think.  

 

Issue #2 Our Solution:

I have had no choice but to update the session class to lower security for IE browsers by introducing a new "_http_user_agent" function. 

private function _http_user_agent() {
	return strstr($_SERVER['HTTP_USER_AGENT'], 'Trident') ? 'IEX' : $_SERVER['HTTP_USER_AGENT'];
}

You can grab the latest classes/session.class.php file on GitHub. Please let me know your GitHub username if you want pull access. Alternatively I have uploaded the current version here.

session.class.php

Link to comment
Share on other sites

I sent you login info in a PM if you are interested in seeing the phpinfo and other settings. I backed out my kludges on the development install so the paypal plugin checkout process can be fully tested.

 

Last week I did move the site to a new dedicated server, BUT it was up and running (V5.1.5) for 3-4 days before I upgraded on Sunday, and the Paypal payments were working (to the extent that they had been previously) so I would be surprised if server settings alone were the culprit.

Link to comment
Share on other sites

Some kind of bad formatted code on one of the return pages forcing it into whatever passes for a quirks mode these days maybe? Sounds a bit weird if they're all changing user agents on return from paypal.

 

Hmm, or what if it's on the paypal side of things that it forces the agent into a lower version that it happens to remain on when you return to the site?

Link to comment
Share on other sites

As a brand new Cubecart user (just paid today as a matter of fact) this was the first issue I struck (and the paypal plugin was the reason I bought it as a matter of record).

 

Using Google Chrome.

Customer is logged in.

Quick checkout Paypal sandbox (btw, no product/order showing in Paypal - order showed fine in gateway mode)

Come back to site and I'm *logged out*

Admin shows order was made and is pending (pending is a sandbox quirk apparently so no issue - I think)

Relog as customer, order is showing as pending

Make effort to "complete payment"

Go through exact same process, same result......and I now have 2 orders

 

Site is Australian. All settings for Australia. Paypal Gateway worked OK (except no order details?!) but it DID work.

 

Bit disappointed to say the least. 

 

Any word on solution here?

 

EDIT: Just tested with Firefox, same issue. TOKEN changed is all. Also tested through cart/paypal instead of quick checkout and same result.

Link to comment
Share on other sites

Welcome fCommerce! Glad to see you made it to the forums.

 

Is there any way you can observe the incoming and outgoing headers during your various page requests?

 

One theory being explored is that at some point, the customer's browser decides to not include the cookie CubeCart gave the browser (at the beginning of their shopping session) in the request for the next page in CubeCart's checkout process.

 

Using any modern browser, each has their method of inspecting the Request and Response headers. CubeCart's is PHPSESSID and is tied to your domain.

 

Also, compare the User Agent string being stated by the browser before it visits the PayPal site, and the UA string after it visits the PayPal site.

 

We appreciate your participation in our efforts to lock this down.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...