bsmither Posted October 8, 2014 Share Posted October 8, 2014 This sounds SagePay's FORM method. I'll study the manual and try to learn something. Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 Thank you for your help. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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). Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 The callback URL is storeurl.com/index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=111111-111111-1111A Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 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?" Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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??? Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 We just updated cube cart from 5.2.11 that was the only change we made. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 I will make a code comparison between CC5211 and CC5213. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 Ok, let me know what you want me to try and i'll give it a bash! Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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>' ; Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 Ok in notes it's now saying "SagePay - no indicator." Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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? Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 I do have a list of raw access details, but it's a big list of files loaded etc. What should I look for? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 8, 2014 Share Posted October 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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'. Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 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&crypt=@de316aff41b4b5d404d8f755f14776f402d374242decff36d21b7d1cbc63f5e57e1622d07c7919c9d936abff814c119c7f6c178c24d0a8798c7ddbdcc03a83201b5ec82518bc5f7d43254bbfc416d5f11270be370b6ef22ac83ca7d818ba8a6f2e56feabb653cfe3f3d4da19efa61ae31825ec8766bfbfff68da674ee8c3ec6bd84fd8826438d6dd1e6ea3f6ca7ff9ffd32fea75a11104f0f8b26f98564f2ce19e9be4de5a3cd65a154a90688be135b87c55859dc100877ddf02980bdca484214ec6087f64fafcff18a5ae2017dfde360040f55ed4e0e0531a554726a5c6d869852c027aa5227c473a30602c5cf74b60552e65a9759d7fda0ff71c8b9fe68d861b19f6be789cca7f0a86bcf1f0afc98563dfe91875b15c3417d06bef41ff80f87bb3afcb0402e32262ad5d1388dc0e0545ac55e1adc899d064e267ef61c355df137ed2a9e6493a857a3eb82ff166052709efa4ee564287b202d0871edf903d473c95f4db6e12cf9a1944271a62191077a99b4c04cb7691e9ec823ad9fd512edc0e4543c1dfc28b3bc2c86ef3ba547c75 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" ? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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? Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 8, 2014 Author Share Posted October 8, 2014 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? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 8, 2014 Share Posted October 8, 2014 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? Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 9, 2014 Share Posted October 9, 2014 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. Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 9, 2014 Author Share Posted October 9, 2014 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? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 9, 2014 Share Posted October 9, 2014 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 Quote Link to comment Share on other sites More sharing options...
Kristoff Posted October 9, 2014 Author Share Posted October 9, 2014 Looking at this page: https://clients.evohosting.co.uk/knowledgebase.php?action=displayarticle&id=81 They're all the same format of numbers? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.