X-Cart forums

[Jarron]

Hi All,

I'm seriously stuck on this one and any help GREATLY appreciated!

Introduction:
I am using Fast Lane Checkout and I am trying to pass a custom field from the "Shipping & Payment" step of checkout back to cart.php when the user submits "cartform".

Under this scenario, "cartform" is found in checkout_2_method.tpl.

Code:
In checkout_2_method.tpl I have added the bottom input ("delivery_date"):

<form action="cart.php" method="post" name="cartform" id="cartform" onsubmit="return UpdateDeliveryDate();">
 
<input type="hidden" name="mode" value="checkout" />
<input type="hidden" name="cart_operation" value="cart_operation" />
<input type="hidden" name="action" value="update" />
<input type="hidden" name="delivery_date" value="2008-08-23" />

In cart.php I have added the following at the very top of the file to help me with debugging:

define('USE_TRUSTED_POST_VARIABLES',1);
$trusted_post_variables = array("delivery_date");
 
var_dump($HTTP_POST_VARS);
var_dump($HTTP_GET_VARS);

Note that I added the trusted variables stuff as I thought this might be related to the html stripping that xcart does on non-trusted post variables. However, this turned out to be irrelevant.

Debug Results:
After clicking "submit", the page submits and opens up with the "Place order" step with my debug output at the tp of the page:

1) The var_dump for POST gives me:

array(0) { }

ie. No POST vars are found by cart.php

2) The var_dump for GET gives me:

array(1) { ["mode"]=> string(8)"checkout" }

ie. A subset of the POSTed vars are found by cart.php but they have been switched to GET vars.

Analysis:
So my analysis of all this is:

• All POSTS are somehow being intercepted before they get to cart.php
• Logic exists somewhere to decide which ones get through
• Somehow the ones that continue are converted to GETs (probably using header/location?)

Note additionally that:

• My debug code in cart.php is before any includes/requires to auth.php or any other file. So this is unrelated to any REQUEST parsing logic in auth.php or it's includes (which I believe includes all of the $trusted_post_variable and html tag stripping logic).
• I have examined ".htaccess" wondering if there could be some kind of <Limit POST> logic. There is no such logic.
• Other debug variations in cart.php to detect the posted variable (like $GLOBALS["HTTP_POST_VARS"], $delivery_date, $_POST) also do not work.
• Obviously the above is a code snippet - I have validated the full HTML code using validator.w3.org
• I have also looked for any javacript that might be preprocessing the form submit (eg. by using onsubmit) but could find none.

Conclusion:
So it seems to me that something must be intercepting my posted values and parsing them (probably for valid security reasons). But what?

I've tried every avenue I can think of and searched this forum to death....

Any clues will result in a free love child. Yes, I'm desperate.

Fingers Crossed & thx all,

js

[Piotr M.]

Try just $delivery_date variable. X-Cart unsets all superglobal arrays for security reasons.

[Jarron]

Thx Balinor,

I read about this and already tried using $delivery_date.

Does not work - cart.php knows nothing of $delivery_date.

I guess the question is:

1) Where are the superglobal arrays unset? I suspect it is the same place where $delivery_date (and the other hiden inputs) are being stripped out?

2) How are my POST requests being redirected to this place?

I don't THINK it is in auth.php or prepare.php.

Any ideas?

[Piotr M.]

In this case you even don't need trusted post variables if there is no html code inside $delivery_date.

As far as I know it's prepare.php try var_dump before and after including auth.php

[Jarron]

1) Yes, I agree that trusted post variables probably is not relevant here.

2) As suggested, I tried var_dump before and after the auth.php include. No sign of delivery_date anywhere...

To be sure, I tested using empty() and isset() - both return values suggesting $delivery_date is not set.

3) So then I looked in to auth.php, prepare.php & top.inc.php. The only filtering these seem to do is:

- Identify all variables using php's get_defined_vars() function
- Compare these to a list of restriced var names ("GLOBALS","HTTP_GET_VARS","HTTP_POST_VARS","HTTP_SERVER_VARS","HTTP_ENV_VARS","HTTP_COOKIE_VARS","HTTP_POST_FILES","__key","__val","_GET","_POST","_SERVER","_COOKIE","HTTP_RAW_POST_DATA
)
- Remove the posted variable if it clashes with the restricted var names or is not a key within one of them.

So nothing stopping delivery_date being passed here (right?).

4) Next I tried get_defined_vars() at the beginning of cart.php. It showed various variables but not delivery_date.


I'm baffled. Some ideas that might get me there:

a) It seems like the issue is somewhere between posting from html and cart.php being called.

b) The only thing I can think of is that (in additon to the above checks) xcart is redirecting my posts for manipulation somewhere else before cart.php even sees them.

Does this sound feasible? I just can't think of any other logical explanation.

If so - where would it be redirecting and how?

Any ideas?

thx again in advance,

js

[Piotr M.]

Did you used just var_dump or insert exit or die instruction after it?
After processing POST request cart.php redirects browser to itself. This is standard method to avoid resending data if user refreshes page.

[Jarron]

That last tip about the redirecting to itself was what I was missing. THANK YOU!

But pls understand if I don't deliver on the love child.....

For those who follow, was resolved by adding the following to cart.php:

if (!empty($delivery_date))
$url_args[] = "delivery_date=".$delivery_date;

...below this:

if (!empty($paymentid))
$url_args[] = "paymentid=".$paymentid;

This makes the posted variable $delivery_date available to all code in cart.php following this redirect:

if ($return_url)
func_header_location($return_url);

This forum is fantastic - few forums offer such benevolent experts willing to give others a hand. I applaud all that contribute.

thx & I hope this solution helps someone else,
js