A large form on a SS 3.1 site has been working without hiccup. Lately though, I regularly get the following error when submitting forms from Safari:
"There seems to have been a technical problem. Please click the back button refresh your browser, and try again."
Doing the following did not make a difference:
- Clearing the browser cache
- Flushing SilverStripe cache (or manually deleting cache folder contents)
Restarting the browser(Restarting the browser makes the form work again but as soon as another 400 error occurs the problem resurfaces)
- Restarting the web server
It has occurred more frequently on my dev machine (MAMP Pro)
and now has occurred on the production server (Linux) (haven't been able to easily reproduce on Linux easily). And strangely it only seems to be occurring on Safari (able to replicate error on desktop [Mavericks/Lion] / iPad [iOS7] ). It has only started to occur recently. Some recent changes made include adding more fields to the form, changing the system temp directory and php session folder. I can confirm that the sessions folder is where I want it to be because of the newly written session files. If I open the form up, sleep the computer / device,
Just as quickly as it occurs, it stops - and I have no idea why! Everything starts out fine, but when a PHP session timeout occurs and after I get the genuine SecurityToken error, it seems to get itself into a cycle where every subsequent attempt to submit the form (from Safari) results in the same error. I've put in debug statements that show that upon submission, when the form is submitted, the Form object is created (again) and thus a new SecurityToken is generated causing the mismatch.
The following CSRF protection code in Form.php (~ line 280) is where the error is thrown:
// Protection against CSRF attacks
$token = $this->getSecurityToken();
"There seems to have been a technical problem. Please click the back button,"
. " refresh your browser, and try again."));
Debugging and stepping through the code confirms that there is a mismatch in the tokens. But why? Any idea why this could be occurring?