Jump to content

Archived

This topic is now archived and is closed to further replies.

Kristoff

Issue with SagePay 3.0 and digital downloads after update... again...

Recommended Posts

This sounds SagePay's FORM method. I'll study the manual and try to learn something.

Share this post


Link to post
Share on other sites

When you contact SagePay, please tell them that the 'Crypt' field is not being appended to the SuccessURL.

 

As stated in their Form Integration Documentation:

Appended to the SuccessURL or FailureURL is an encrypted field, again called Crypt, which contains the Status of the transaction, the reference code for those transactions and the fraud checking results. The field is decoded in the same manner that your original script was encoded, using the same password (which is known only to you).

 

Share this post


Link to post
Share on other sites

The callback URL is storeurl.com/index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=111111-111111-1111A

Share this post


Link to post
Share on other sites

SagePay's response...

 

"Protocol 3 been out over a year no problems. Cubecart may allow you to roll back to 2.23 so you can trade while they fix?"

Share this post


Link to post
Share on other sites

I was hoping SagePay would watch your account's activity (monitor the traffic somehow) and verify if the 'crypt' field actually got added to the SuccessURL sent back to your store, and if it didn't, could immediately tell you why it wasn't there.

 

I am wondering if the update (did we learn from what version of CubeCart you recently upgraded from? or was it a PHP upgrade?) is knocking off the 'crypt' field because of its length???

Share this post


Link to post
Share on other sites

In the SagePay code, there are a number of insignificant changes (having to do with the removal of the XOR encoding).

 

One other change I see is the addition of a BillingAgreement=0 (for future use in the FORM method) added to the Request Form Fields, where the documentation says this is an optional field within the 'crypt' field.

 

We can try to move this field and see if anything changes.

 

One other test I want to make is to add another field to the FailureURL to distinguish it from the SuccessURL, just to see which URL is being used by SagePay.

Share this post


Link to post
Share on other sites

In the gateway file, near line 266, add // in front of 'BillingAgreement' => 0. This is an optional field for the 'Crypt' field, so it's not necessary to add it there.

 

On line 220, find and edit:

Was:
."&FailureURL=".$GLOBALS['storeURL'].'/index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id='.$this->_basket['cart_order_id']
 
Now:
."&FailureURL=".$GLOBALS['storeURL'].'/index.php?f=1&_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id='.$this->_basket['cart_order_id']

Then we test:

Was:
$REQ_keys = print_r(array_keys($_REQUEST]), true);
$transData['notes'] = 'SagePay Keys: ' . $REQ_keys . '<br>';
 
Now:
$transData['notes'] = (isset($_REQUEST['f'])) ? 'SagePay - used failURL.<br>' : 'SagePay - no indicator.<br>' ;

Share this post


Link to post
Share on other sites

So SagePay must be using the SuccessURL, but still no 'crypt' being received.

 

In your hosting account's control panel, are you given the opportunity to look at the raw webserver access log?

Share this post


Link to post
Share on other sites

An access from sagepay's IP address (might be hard to discover that), but the entry will have:

GET index.php?_g=rm&type=gateway&cmd=process ......

 

It may be quite a long entry.

Share this post


Link to post
Share on other sites

Sorry I've not been more involved here. I have to give the support helpdesk priority amongst other things I'm up against.. Sadly the forum just has to be lower on my list but I would love to be able to spend more time here. :(

 

Brian has been very helpful here indeed as always.

 

The changes from 2.xx to 3.00 are fairly insignificant aside from dropping xor. The most important thing to note here is that if SagePay displays the payment form then your server IS working with AES (mcrypt) perfectly and all data sent to SagePay is pristine. It will sh!t a brick at the most minor thing.

 

Ok.. the crypt var sent back uses the same encryption method is it does on the way out. I expect that its not being sent or its being lost somehow.

 

If you can send a tech support ticket with store admin login and FTP access I will debug this thoroughly for you. We haven't had any other reports of issues aside form this on github which will only affect purchases from the US.

$cryptVars .= "&DeliveryState" .$this->_ci($this->_basket['delivery_address']['state_abbrev'], CLEAN_INPUT_FILTER_TEXT);

Should read:

$cryptVars .= "&DeliveryState=" .$this->_ci($this->_basket['delivery_address']['state_abbrev'], CLEAN_INPUT_FILTER_TEXT);

It could be something quite hard to pinpoint like a .htaccess redirect possibly dropping post data if SSL is forced in there and the return URL is not under SSL. 

Share this post


Link to post
Share on other sites

The $_REQUEST is fully populated with the necessary keys (post #21) except for the 'crypt' key.

 

If the web server is truncating the querystring (assuming SagePay appends to the querystring), we should still have the 'crypt' key but with a short value.

 

If PHP is discarding a $_GET key because its value is too large, I think there would be an entry in the error_log.

 

Both possibilities are utterly ridiculous, and yet, I recently had to make an adjustment to my web server config to allow a POST of greater than 10MB. Just sayin'.

Share this post


Link to post
Share on other sites

An access from sagepay's IP address (might be hard to discover that), but the entry will have:

GET index.php?_g=rm&type=gateway&cmd=process ......

 

It may be quite a long entry.

 

GET /index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=141007-153513-2593&[email protected]c63f5e57e1622d07c7919c9d936abff814c119c7f6c178c24d0a8798c7ddbdcc03a83201b5ec82518bc5f7d43254bbfc416d5f11270be370b6ef22ac83ca7d818ba8a6f2e56feabb653cfe3f3d4da19efa61ae31825ec8766bfbfff68da674ee8c3ec6bd84fd8826438d6dd1e6ea3f6ca7ff9ffd32fea75a11104f0f8b26f98564f2ce19e9be4de5a3cd65a154a90688be135b87c55859dc100877ddf02980bdca484214ec6087f64fafcff18a5ae2017dfde360040f55ed4e0e0531a554726a5c6d869852c027aa5227c473a30602c5cf74b60552e65a9759d7fda0ff71c8b9fe68d861b19f6be789cca7f0a86bcf1f0afc98563dfe91875b15c3417d06bef41ff80f87bb3afcb0402e32262ad5d1388dc0e0545ac55e1adc899d064e267ef61c355df137ed2a9e6493a857a3eb82ff166052709efa4ee564287b202d0871edf903d473c95f4db6e12cf9a1944271a62191077a99b4c04cb7691e9ec823ad9fd512edc0e4543c1dfc28b3bc2c86ef3ba547c75 HTTP/1.1" 302 26 "https://live.sagepay.com/gateway/service/authorisation" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36"
 
?

Share this post


Link to post
Share on other sites

Well, well, well! There it is!

 

Thanks to your efforts and willingness to make these experiments, we have absolutely narrowed down the problem.

 

It is not SagePay -- they do include the 'crypt' key in the querystring.

 

It is not the front-side of the web server because it dutifully recorded the access.

 

It is not the SagePay module because &_REQUEST['crypt'] has already gone missing.

 

The CubeCart code that handles the _g=rm is very straightforward. There is no code here that could discard $_REQUEST['crypt'].

 

That leaves the server back-side (the part that starts PHP and passes along a bunch of data to PHP). Maybe it has some sort of security appliance. It would be a huge coincidence if there was a server configuration change at the same time as the CubeCart upgrade.

 

Or it leaves PHP discarding the 'crypt' key when converting the querystring to a $_GET array. Maybe there is a PHP security plugin. Again, a huge coincidence if PHP was upgraded at the same time.

 

I wonder how to test the above two hypotheses?

Share this post


Link to post
Share on other sites

When we upgraded it won't have made a difference on PHP versions I guess as we were using the other type of verification on the old SagePay gateway and if you look at the thread I linked at the start of this thread, it seems we were having those problems way back then, I just worked around the way the payment was made, which is now no longer an option?

Share this post


Link to post
Share on other sites

The key difference between XOR and AES, other than the actual encryption, is that an AES response from SagePay includes a leading '@' character.

 

You say that before the upgrade, you were having problems with AES. I would assume you mean the same end result that you are experiencing now -- pending orders and no real info in the transaction logs.

 

Which suggests strongly to me that the exact location of the problem can be focused on how your installation of your web server, your installation PHP (regardless of version), or an installation of some sort of security system tied into the web server or PHP is configured. Any of these may see the '@' as an illegal character. (Which it is not.)

 

@Havenswift, are you aware of any such configuration setting in a web server, PHP, or security appliance that would trigger on an '@' character?

Share this post


Link to post
Share on other sites

One thing I have certainly noticed recently is that more and more servers are ignoring POST variables specifically with larger forms. I haven't seen this with GET yet.

Hence.. https://support.cubecart.com/index.php?/Knowledgebase/Article/View/215/40/my-store-redirects-to-the-admin-dashboard-when-i-click-save

Does Apache log any error codes with notes such as "unacceptable"? Security settings can indeed block. Frustratingly the same security setting can have different behaviour on different server setups from my experience in the way the error is handled. Some just pretend nothing happened removing "bad" data, some throw fatal errors etc..

I expect there is a log file somewhere with precise detail in.

Share this post


Link to post
Share on other sites

I've asked my host about it and they suggested switching the account to use their custom PHP 5.4 build:

AddHandler application/x-httpd-php54 .php

At the top of the htaccess file, but that just threw up a blank page?

Share this post


Link to post
Share on other sites

I have no knowledge about these types of .htaccess statements, but that one seems weird. I would think that, if that statement is appropriate, it should be -php5.4

Share this post


Link to post
Share on other sites

×
×
  • Create New...