Ajax script from 1.3.x hitting 'time_out' page because of action and method

[neekfenwick]

Hi guys,

I thought I'd describe what I just encountered and see if there anyone particularly recommends a specific way of working around it. I'm bringing an ajax script over from a 1.3.8 Zen Cart called ajaxHandler.php. It sits in the root of the site and handles GET and POST requests from various bits of javascript I've extended Zen Cart with in our environment.

I've run into trouble with POST requests, because the requests in general look like this:
GET /ajaxHandler.php?action=get_something&param=foo
POST /ajaxHandler.php with post data action=save_something field=whatever

The GET completes just fine, but my POST results in the time_out.php response being sent back to my ajax handler, which obviously blows it up as it's nothing like the nice JSON response it was expecting.

There is code in init_sanitize.php in 1.5.1 that does this:

  if ((isset ( $_GET ['action'] ) || isset($_POST['action']) ) && $_SERVER['REQUEST_METHOD'] == 'POST')
  {
    $mainPage = isset($_GET['main_page']) ? $_GET['main_page'] : FILENAME_DEFAULT;
    if (!in_array($mainPage, $csrfBlackList))
    {
      if ((! isset ( $_SESSION ['securityToken'] ) || ! isset ( $_POST ['securityToken'] )) || ($_SESSION ['securityToken'] !== $_POST ['securityToken']))
      {
        zen_redirect ( zen_href_link ( FILENAME_TIME_OUT, '', $request_type ) );
      }
    }
  } 

So, in the case of my POST, if an 'action' $_POST parameter exists, it enters this if block, and will then redirect to the "time_out.php" page if a securityToken session variable doesn't exist.

There seem to be two immediate solutions:

1. change my 'action' parameter to something else. I've changed it to 'activity' and the offending if block is no longer entered and my script works fine.
2. somehow make sure a $_SESSION['securityToken'] is set, so that even if this if block is entered, it passes the security test. I don't know anything about securityToken and would appreciate a little advice about how to go forward with it.

It seems to me that this hardcoded behaviour around the 'action' parameter is specific to Zen Cart, and it would be wiser to follow solution 1 and change my script at that logical point rather than to dig deeper. That is, not try to make my script fit into this expected parameter pattern of Zen Cart, because my script is not a core Zen Cart script. This is quite a pain, because all the stuff I'm bringing over from our old 1.3.x site uses the ajaxHandler.php script fairly heavily, so "action=whatever" is coded into many places and makes bringing the scripts into 1.5.1 more painful. I would guess Zen Cart is making sure things like customers.php?action=delete_customer are made to pass a security check.

On the other hand, perhaps I should make my script play nice with Zen Cart and set up a $_SESSION['securityToken']. Unfortunately, debugging this init_sanitize.php point in time during the request, I see no $_SESSION set up at all, even in the GET request to the admin script that loads the page (in my case /admin/product_videos.php, 'admin' is obviously something different).

So, do people generally make sure their ajax scripts don't send an 'action' parameter in their POSTS to avoid this problem, or do you try to make your ajax scripts set up a session and securityToken variable to make this test pass?

Advice appreciated :)
Nick