If a form stopped working when you upgraded to v1.5.0+ …

 v1.5.0, v1.5.1, zen-cart  Comments Off on If a form stopped working when you upgraded to v1.5.0+ …
Mar 122013
 

One of the things that changed in Zen Cart v1.5.0 was an additional security check to make sure that forms submitted via the POST method were coming from the active session.  This is great for the security of your store, but can have unintended consequences.  Essentially, if a form is sent to your site via POST that doesn’t include a securityToken variable whose value matches the session-variable of the same name then that form is rejected and a redirect is performed to either the page_not_found (v1.5.0) or time_out (v1.5.1+) page.

This check can have unwanted result for some of your customizations, especially if those customizations code the HTML <form> tags directly instead of using the zen_draw_form function.  That function was updated in v1.5.0 to include, for forms to be submitted via POST, a hidden field named securityToken that contains the current session’s securityToken value.  If your customizations use that function to draw their form, all is well.  If, on the other hand, the <form> tag is created directly and doesn’t include the securityToken’s hidden field the form will not be accepted and result in the redirect mentioned above.

I’ve seen this behavior reported in the Zen Cart forums, usually associated with either a store-specific customization or a plugin that was developed for the v1.3.x Zen Cart series and carried over when the store was updated to v1.5.0 or later.