Jump to content

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

Recommended Posts

The next test:

$transData['notes'] = (isset($_REQUEST['f'])) ? 'SagePay - used failURL.<br>' : 'SagePay - no indicator.<br>' ;
$transData['notes'] = 'SagePay - SQS: ' . $_SERVER["QUERY_STRING"] . '<br>SagePay - SRU: ' . $_SERVER["REQUEST_URI"] . '<br>';

This will tell us what the web server is giving to PHP with respect to the querystring.


By the way, do we know what the webserver software is? Apache? nginx? Lightspeed?

Link to post
Share on other sites

  • Replies 66
  • Created
  • Last Reply

Top Posters In This Topic

SagePay - SQS: _g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=141009-193950-4190&[email protected]8a3efb2bf48fe741b275ae997e371905606573833d90cdffdd115dead7be5b9b7ba2fa706e1c83ee619f7ca2ffa19aed3af5ecd5405e533d4bba087c7813639328c8991dca5387dfc45a98aaaecb4b6ee8818cb0500064990eef6b40d27b5cbf0de47eb6622d83a56371a63e45a1fcb3e2dc8b79c96aa050d2f1ed0951588717366482e75aa3b0ff9868908be993e801c0bfb66c5c06a1fca7a2ffe6bc26dfaf7450dae0eb6e807ea63274ae0010161c0803e215c50eef0eedb7d10ab68ad29a321df954f36afc233dee27b43e58a9b026961fbc5165db924170596bde6c592e897bf4e0ad585d01cab0bd90e1e29f5c07741f57b25bd18c63562bc5e2cb294318d085d070b15db84f8b97f6c17184c54ffbf821516daa231ea88af5176cffa175d9b9c37b94619c497672a1d9328291c8867fff721ac1be488a8b33315662b79fc9ddaac80c7bb4e43b88a163a45452c8ac27d3003a34e58f252588bc423e424c3f8a778dd86f80ae202fab6a824b60b84b66b
SagePay - SRU: /index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=141009-193950-4190&[email protected]8a3efb2bf48fe741b275ae997e371905606573833d90cdffdd115dead7be5b9b7ba2fa706e1c83ee619f7ca2ffa19aed3af5ecd5405e533d4bba087c7813639328c8991dca5387dfc45a98aaaecb4b6ee8818cb0500064990eef6b40d27b5cbf0de47eb6622d83a56371a63e45a1fcb3e2dc8b79c96aa050d2f1ed0951588717366482e75aa3b0ff9868908be993e801c0bfb66c5c06a1fca7a2ffe6bc26dfaf7450dae0eb6e807ea63274ae0010161c0803e215c50eef0eedb7d10ab68ad29a321df954f36afc233dee27b43e58a9b026961fbc5165db924170596bde6c592e897bf4e0ad585d01cab0bd90e1e29f5c07741f57b25bd18c63562bc5e2cb294318d085d070b15db84f8b97f6c17184c54ffbf821516daa231ea88af5176cffa175d9b9c37b94619c497672a1d9328291c8867fff721ac1be488a8b33315662b79fc9ddaac80c7bb4e43b88a163a45452c8ac27d3003a34e58f252588bc423e424c3f8a778dd86f80ae202fab6a824b60b84b66b

Link to post
Share on other sites



PHP says it received the 'crypt' key from the web server. But it is not getting transferred into the $_REQUEST array and also probably not into the $_GET array. But let's check the GET array.


More and more interesting because we are getting ever closer to where the real breakdown occurs.

$transData['notes'] = 'SagePay - SQS: ' . $_SERVER["QUERY_STRING"] . '<br>SagePay - SRU: ' . $_SERVER["REQUEST_URI"] . '<br>';
$GET_keys = print_r(array_keys($_GET]), true);
$transData['notes'] = 'SagePay GET Keys: ' . $GET_keys . '<br>';
Link to post
Share on other sites

Could A not be something to do with the A at the end of the Callback URL?




Does that not just seem to coincidental? When using XOR there was an X on the end of this URL to tell the store that it had been sent using XOR.

Or.... Line 322:

		httpredir(currentPage(array('_g', 'type', 'cmd', 'module'), array('_a' => 'complete')));

_a => complete


Is that to tell the script that the payment has been completed?

Also, any idea what "ReferrerID" is on line 244? Should that be related to the store? Or is it that just an ID relating to CubeCart?

Link to post
Share on other sites

Right, I think I know what the _a is. I just changed line 322 from _a to "testing" and after paying got sent to "http://www.site.com/index.php?cart_order_id=141009-203928-6031&testing=complete"


It returned me to the homepage rather than the order page and hasn't added the transaction to transactions. So i'm guessing that _a is telling the store that the payment has been completed?

Link to post
Share on other sites

Having narrowed down where the problem seems to be located, my next test would be to install my tracker code.


Fortunately, where the problem seems to exist can be tested on a local installation because the question that exists with the querystring and how PHP is processing it does not depend on where the querystring is coming from nor the exactness of what it contains.


More shortly.

Link to post
Share on other sites

My tracing with a similar querystring (a cart_order_id that is on my system) shows the 'crypt' key present all the way into the SagePay module where it can be decoded.


So, if Devellion (now CubeCart, Ltd) hasn't said they will get this sorted shortly, maybe I can discover where the 'crypt' key is getting lost on your system.


If you want, send me a PM with your email address.

Link to post
Share on other sites

The conclusion at this point in time is that SuHosin has a setting:

suhosin.get.max_value_length 512

which will deny SagePay's 800+ value for the 'crypt' key from being assigned to the $_GET and $_REQUEST arrays.


We placed the following code in ini-custom-inc.php:

// Override suhosin $_GET limitation
$_GET = array();
$params = explode('&', $_SERVER['QUERY_STRING']);
foreach ($params as $pair) {
 list($key, $value) = explode('=', $pair);
 $_GET[urldecode($key)] = urldecode($value);
 $_REQUEST[urldecode($key)] = urldecode($value);

Initial tests show promising results.

Link to post
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.

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