Encapsulated Plugin AJAX Call Fails with 400 Bad Request in ZC 2.1

[Techiant]

Hello,

I'm developing an encapsulated plugin for Zen Cart 2.1 and have run into a persistent AJAX routing issue.

My plugin successfully injects JavaScript onto the page, and that script makes a standard POST request to ajax.php with an action and method (e.g., ajax.php?act=MyAction&method=myMethod). The POST data correctly includes the securityToken.

When the call is made, the server responds with a 400 Bad Request. This indicates the ajax.php router is receiving the request but rejects the action as invalid.

My AJAX handler class (e.g., class zcAjaxMyAction) and its corresponding file (zcAjaxMyAction.php) are located in my plugin's .../catalog/includes/classes/ajax/ directory. The class and file names appear to follow the standard zcAjaxPascalCase convention.

What is the definitive method for an encapsulated plugin to register its AJAX handler classes so they are discoverable by the ajax.php router? The automatic discovery does not seem to be working, and my attempts to manually register the path using an auto_loaders config file have failed.

Any insight into the correct process for ZC 2.1 would be greatly appreciated. Thank you!

[lat9]

It'll help if you could post the contents of your javascript/jquery and ajax class for review. If you're hesitant to post directly, send them to me via PM.

[Techiant]

It'll help if you could post the contents of your javascript/jquery and ajax class for review. If you're hesitant to post directly, send them to me via PM.

Oh gosh! After smashing my head against this for several hours, I decided to just extensively test ajax.php and log every step. It turns out the issue was that I was setting my method as my_method which in ajax.php was failing at line 51:

if (!isset($_GET['act'], $_GET['method']) || !preg_match('/^[a-zA-Z0-9]+$/', $_GET['act']) || !preg_match('/^[a-zA-Z0-9]+$/', $_GET['method'])) 

I feel super dumb for not paying attention to that regex for $_GET['method'] but relieved that finally made the connection :)

[mc12345678]

Oh gosh! After smashing my head against this for several hours, I decided to just extensively test ajax.php and log every step. It turns out the issue was that I was setting my method as my_method which in ajax.php was failing at line 51:

if (!isset($_GET['act'], $_GET['method']) || !preg_match('/^[a-zA-Z0-9]+$/', $_GET['act']) || !preg_match('/^[a-zA-Z0-9]+$/', $_GET['method'])) 

I feel super dumb for not paying attention to that regex for $_GET['method'] but relieved that finally made the connection :)

Didn't spend quite the same amount of time; however, have found this narrowly applied section of code causes unnecessary issues with other ajax plugins/code. Haven't a clue why an underscore wasn't factored into an allowed character affecting the filename, the class name, and any associated class method. Sure, PSR-1 might be a reason to address/remove it for the class name, but for existing code that wasn't subject to the unrelated issues of arrays and such, it unnecessarily breaks things.

I'm working on reporting the issue in github since it was already somewhat identified as an issue against the original PR but no closure/further reference provided. I'm also trying to find a post asking about use of an associated plugin so I could report to them that no, as written the plugin code has to be modified because of the oversanitization applied in ZC 2.1.0.

Fun part moving forward will be how to support updates to the plugin because now some files have to be modified, renamed *and* "deleted" while some only need modification just to handle this new unnecessary requirement.

[Techiant]

Agreed. I honestly thought there was something wrong with my query, sessions, etc. I mean I have no problem with following new standards, just wish the ajax.php was more verbose about it than just die with 400 status. At least I know where to look next time.

[mc12345678]

Agreed. I honestly thought there was something wrong with my query, sessions, etc. I mean I have no problem with following new standards, just wish the ajax.php was more verbose about it than just die with 400 status. At least I know where to look next time.

There's a number of places where additional verbosity would have been appreciated, more so in github than specifically in the file (though at least some level of "notification" to user is nice).

One needs to also think about what information is given to the malicious user testing the site... Ohh, a bad name? Fine, I'll just change to this... Oh, good name, but.... I mean yeah there's the open-source aspect, just saying failure is failure.

Why having an underscore is a failure? Not at all described in the solution and not part of what was targeted to "fix". As such, problem was a "feature", not intentional.