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

The next test:

Was:
$transData['notes'] = (isset($_REQUEST['f'])) ? 'SagePay - used failURL.<br>' : 'SagePay - no indicator.<br>' ;
 
Now:
$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?

Share this post


Link to post
Share on other sites

Regarding the .htaccess file -- very well.


IF you can actually get a page to load from your site, have your browser show you the headers.

 

Have you told us the web address of your site?

Share this post


Link to post
Share on other sites

You are running Lightspeed (version unknown) and PHP5.3.28.

 

I will ask about this on a web master's forum.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Hmmm....

 

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.

Was:
$transData['notes'] = 'SagePay - SQS: ' . $_SERVER["QUERY_STRING"] . '<br>SagePay - SRU: ' . $_SERVER["REQUEST_URI"] . '<br>';
 
Now:
$GET_keys = print_r(array_keys($_GET]), true);
$transData['notes'] = 'SagePay GET Keys: ' . $GET_keys . '<br>';

Share this post


Link to post
Share on other sites

Is the squared bracket after _GET a typo again?

 

EDIT: SagePay GET Keys: Array ( [0] => _g [1] => type [2] => cmd [3] => module [4] => cart_order_id [5] => _a ) 

Share this post


Link to post
Share on other sites

Oh, fer cryin'...

 

Yes.

 

Hm. Again with the _a. Still wondering where that's coming from.

 

But no 'crypt'. Just as I thought would be the case.

 

Still talking to the experts on another forum.

Share this post


Link to post
Share on other sites

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

 

"siteurl.com/index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order=631636-363616-6313A"

 

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?

Share this post


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?

Share this post


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.

Share this post


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.

Share this post


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:

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

Share this post


Link to post
Share on other sites

×
×
  • Create New...