checkout_payment Error length limitation?

[HowToFoldSoup]

I've been trying to address a traditional blank page problem for a day or so now. This has come up while trying to troubleshoot it.

I am intentionally causing my cart to fail with a bad expiration date on the fake credit card I'm using. Instead of redirecting to the checkout_payment page and asking me to correct the problem, I am getting a blank page.

[I am familiar with all the causes of blank pages and I have turned on error logging, to no avail. My host is not showing any errors in the logs. End tangent.]

I can circumvent the blank page, though, once I reduce the length of the error message to 44 characters.

For instance:

http://www.website.com/zen/index.php?main_page=checkout_payment&payment_error=gateway_services_cc&error=The +expiration+date+entered+for+the+credit+card+is+invalid.+Please+check+the+date+a nd+try+again.

Gives me a blank page, whereas this:

http://www.website.com/zen/index.php?main_page=checkout_payment&payment_error=gateway_services_cc&error=The +expiration+date+entered+for+the+credit+

Shows the correct page with the truncated error.

I don't even know where to begin troubleshooting this or why this might occur. Obviously I'm using the Gateway Services CC payment module, but that seems to doing the redirect correctly. The tpl_checkout_payment_default.php is not overridden, and is identical to the 1.3.9h distributed version.

Any help or insights would make my day! Thanks!
HowToFoldSoup

[DrByte]

Yes. Error messages longer than 46 characters are treated as rogue activity, because that's how intruders work.

The payment module you're using needs to be rewritten to pass the error message via the $messageStack instead of as a URL parameter in zen_href_link. Examples of proper operation can be found in the built-in payment modules.

[HowToFoldSoup]

Aw, man... I was concerned it was something like that.

Thanks for your response. I have a feeling I'll be re-writing this myself.

HowToFoldSoup

[HowToFoldSoup]

This is a related issue with the same configuration. I have re-written the page and am able to get the pre_confirmation_check() errors to display by using the message stack (thanks again for the insight).

My new problem seems to be related to the way the credit card processor is sending to the return URL. For instance, this (a mockup)...

http://www.website.com/zen/index.php?main_page=checkout_process&response=2&responsetext=DECLINED&authcode=& transactionid=12345678912&avsresponse=U&cvvresponse=+&orderid=&type=sale&respons e_code=200&username=12345678&time=20110225094125&amount=10.00&hash=9999999999999 99999999999999999

...shows nothing and generates no DEBUG files.

On the other hand, this...

http://www.website.com/zen/index.php?main_page=checkout_process&response=2&responsetext=DECLINED&authcode=& transactionid=12345678912&avsresponse=U&cvvresponse=+&orderid=&type=sale&respons e_code=200&username=12345678&time=20110225094125&amount=10.00

... returns the appropriate CC Declined message.

Since the return URL that the gateway is using is beyond my control and something I have to speak with the Gateway about, can I assume the white screen of doom (catchy, eh?) is another reflection of the security measures taken to thwart suspicious behavior. Specifically, it seems to not like the "hash" query string item in particular (since if I remove that, it behaves as expected.)

I'm just trying to get as much information about this as possible, so I'm armed to speak with support at the Gateway.

Thanks in advance,
HowToFoldSoup

[DrByte]

If you're encountering a 406 response header when you get the blank page, then it's the internal security measures I mentioned earlier. Anything else suggests a bug.

Specifically the parameter named "hash" is treated as spammy, and triggers the blocking.