Jump to content

CSRF error on admin login


Recommended Posts



I've just upgraded from v5 to v6 of CubeCart (didn't realise it was a beta so may not have as i'm not very tech savvy!)


It seemed to install fine, but i'm not able to login to my backoffice area as it returns the error message -


Security Alert: Possible Cross-Site Request Forgery (CSRF) or browser back button used.


Does anyone know how to fix this please (the more simplistic answer the better!)


Thanks for any help.

Link to comment
Share on other sites

Hi Ian,

I only have 1 installation of CubeCart on my site, and i'm not logged into anything else when trying to login to my admin area.

I have used the same url path etc and (as far as I know) just overwritten the old v5 files with the new v6 files.



Link to comment
Share on other sites

In every web form, CubeCart includes a hidden form element with the name "token". This token is compared with the token last generated by CubeCart and which was populated onto the Smarty template. It gets regenerated after every POST. So, only the templates rendered after the last POSTing have the current token.


I recently ran into an issue where the token was being regenerated after every page delivery. That is, the page was rendered and delivered with a token, then, during shutdown, CubeCart decided to generate another token. It was always a mismatch. The storefront would never allow for a customer to log in, and the same for admin, but with admin there is an additional warning message.


It was a bugger to make it stop. I don't know what finally worked, but I deleted all the pertinent cookies from the browser, made sure the browser was not pulling any pages from it's cache, and in the CubeCart_sessions table, I deleted all records there.


In earlier versions of CubeCart, I asked for this page three times, then cleared cookies, and I finally got out of the loop:

Link to comment
Share on other sites



I've tried all your tips (apart from the CubeCart_sessions table step as i'm not sure where that is), but am still locked out.


After a few attempts at the page request I noticed this line right at the top of the login screen -


Warning: filesize(): stat failed for /var/sites/z/mystore.com/public_html/business/meals-made-easy/order/cache/60678.sql.158556ada154a57dc786a4e4a95ba908.cache in /var/sites/z/mystore.com/public_html/business/meals-made-easy/order/classes/cache/file.class.php on line 176


(I've replaced my actual store name with 'mystore' in the above error message)


The message only appeared once in my 5 or 6 attempts, could this have anything to do with it?


Thanks for your help

Link to comment
Share on other sites

Let's try this: on a computer that has never seen your store before, try to log in.


If you get the same message, I will be flummoxed. FTP into your site and delete everything in the /cache/ folder.


As for the "stat failed" warning, I think that is not contributing to this problem.


Also, and this you may not know how to do, but use your browser's "Developer" or "Diagnostic" mode. This feature will allow you to watch all the traffic that your browser sends and the responses it receives. We can determine if your browser is making any extra GET requests that may be triggering the token generator.


Also, when you upgraded, did you leave in place any third-party plugins?

Link to comment
Share on other sites

Do you have any other PHP applications running on your domain name? That you access frequently? If so, that could a contributor to the problem.


In the file /ini.inc.php, make this edit near line 51:

ini_set('session.name', 'PHPSESSID');
ini_set('session.name', 'CC600B4');

If there is another PHP application on your domain name, and your browser has the cookies for that other app, and that app also uses the (sometimes set as default in the php.ini file) session identifier PHPSESSID, then confusion could occur.


Recent versions of CC5 (and part of CC6) added a "cookie domain" to the session management (admin, Store Settings, SSL tab). If that isn't set, maybe that also contributes to the problem.

Link to comment
Share on other sites

Another customer reported this issue today and it turned out that the server was failing to write session data to the specified path in the php.ini config file. It was fixed by creating a folder in the CubeCart root install location called "sessions". I then created a file in the store root called "ini-custom.inc.php" with the content.


This fixed it. 
Link to comment
Share on other sites

Thank you all for all your help.


I have decided I am out of my depth playing with a beta (v6) so have downgraded back to v5.2.16.


I now have the problem that in admin my store settings (adding logo, updating store name etc) won't take hold.  I can alter the homepage text in documents and that changes fine, but store settings (even taking my store offline) will not change anything on the front end.


Could you please point me to any help for this issue, and I thank you again for trying to fix my venture into v6.

Link to comment
Share on other sites

Hi Ian, testing session_status proved useless in that it can't be used to check for errors.


The following patch works like a dream. From my experience I've seen a lot of hosting companies with bad session config so this is quite a common problem. e.g. https://www.powweb.comfrom memory.



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...