Gazley Posted March 31, 2014 Share Posted March 31, 2014 Hi there, I've just received notification that a user trying to login to a site is getting the above message. I've viewed a number of threads in the forum about this error message but I can't seem to see a comparison. The logins to the site have always been OK and I have made no changes recently. Logins were working fine and suddenly, overnight, this error is being raised. I can't access the site right now because I'm away from my dev box. I just thought I'd ask if anyone has a view on what kind of things might have changed on the server for it to start raising this error? Many thanks. Link to comment Share on other sites More sharing options...
WillyC Posted March 31, 2014 Share Posted March 31, 2014 tells user.restart browser ? try disable csrf if no fix /site/config.php u try $config->protectCSRF=false; gazley dark, beard.looking good keep working.at it too 5 Link to comment Share on other sites More sharing options...
Gazley Posted March 31, 2014 Author Share Posted March 31, 2014 Hi WillyC Thanks for the heads-up. I've tried logging on myself from a different browser, different machine and I get the same issue on any login that I try? I'll keep working on the beard too Cheers. Link to comment Share on other sites More sharing options...
pwired Posted March 31, 2014 Share Posted March 31, 2014 Check your web host what they recommend for their server-writable directory permissions, 1. is your /site/config.php readable ?2. 644 on config.php and 755 on /site/assets/ should normally work3. try to set /site/assets/ to 777 and recursively all inside /site/assets/, Link to comment Share on other sites More sharing options...
pwired Posted March 31, 2014 Share Posted March 31, 2014 Try to replace your index.php file with one from the dev branch and see if that works. Link to comment Share on other sites More sharing options...
Gazley Posted March 31, 2014 Author Share Posted March 31, 2014 Hey Guys, Thanks for the great tips and advice around this. I came across this: https://processwire.com/talk/topic/1563-this-request-was-aborted-because-it-appears-to-be-forged/?p=46616 I checked out the disk size and sure enough, it was out of space! I resized the drive and the problem immediately went away. We've just enabled secure login so that users can view their own galleries and the session cache was choc full of expired sessions. I assumed that PHP would remove the sessions once they expired but clearly, this isn't the case. Is there any particular guidance around the removal of session files? Anyway, problem solved - thanks again! Link to comment Share on other sites More sharing options...
SiNNuT Posted March 31, 2014 Share Posted March 31, 2014 PW should and would remove stale session files. In some cases this so-called garbage collection does not work, especially on Ubuntu servers. Adding a couple lines of PHP to config.php solves this problem for most people. more info here: https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/?p=56596 7 Link to comment Share on other sites More sharing options...
Gazley Posted March 31, 2014 Author Share Posted March 31, 2014 Hi SiNNut, Yep, it's an Ubuntu server. Thanks very much for the link Link to comment Share on other sites More sharing options...
OrganizedFellow Posted September 11, 2014 Share Posted September 11, 2014 Had this error also. I'm using OpenShift with 1 gear as my development server. It's some good practice with GIT I SSH into my server and noticed that /site/assets/cache, logs, and sessions JUST DID NOT EXIST. Totally weird, right? Well, not totally. I had them listed in my .gitignore file. I read elsewhere on the forums that they should be added. So I had originally created/installed PW on my local machine and when I pushed the master UP, of course, cache logs and sessions didn't work. So I manually recreated them and so far ... yeah, it's working fine. OH, version 2.4.18 dev. Link to comment Share on other sites More sharing options...
LostKobrakai Posted September 11, 2014 Share Posted September 11, 2014 @OrganizedFellow Maybe just exclude contents of those folders, so the folders themself get pushed to your git server. 2 Link to comment Share on other sites More sharing options...
Nico Knoll Posted September 11, 2014 Share Posted September 11, 2014 Scroll down a little and try the tricks on this page: http://processwire.com/docs/tutorials/troubleshooting-guide/page2 2 Link to comment Share on other sites More sharing options...
drpuff Posted January 14, 2015 Share Posted January 14, 2015 @OrganizedFellow Yes, same here. This worked for me too....along with a quick change of .gitignore! Thanks. 1 Link to comment Share on other sites More sharing options...
shamus Posted January 24, 2015 Share Posted January 24, 2015 (edited) I have already replied to a related post by Joss (https://processwire.com/talk/topic/8672-forged-again/) but I just came across this topic and seems there's been a lot more discussion here regarding this "forged request" issue. Anyways, I'm running PW 2.5.3 and am experiencing the dreaded "TemplateFile: This request was aborted because it appears to be forged." error described herein while trying to log into the admin interface AND using a mobile device running iOS. I have tested the admin login successfully using droid mobile devices (both phone and tablets) , along w/ most desktop browsers including IE8-11, FF29+, and most recent Opera and Safari versions. Curious if anyone has experienced the same thing w/ iOS 7 and has a recommended fix? Note: since find this post, I have tried using Nico's tips in his troubleshooting guide regarding altering CSRF config settings (e.g. $config->protectCSRF = false;$config->sessionChallenge = false; $config->sessionFingerprint = false;). After integrating these changes, this resulted in my login request being bounced back to admin login form, without any error (and failed login). ------------ PLEASE IGNORE: FIXED ---------------------------------- Cookies must be enabled...had wrong settings. Edited January 27, 2015 by shamus 1 Link to comment Share on other sites More sharing options...
guy Posted March 1, 2015 Share Posted March 1, 2015 To add to the above: We experienced this issue with an established site when moving from http to https. Login requests either threw this error or simply returned you back to the login screen after silently failing. Following trying all the suggestions posted by Nico - apart from /site/assets/ chmod 777 - as he mentions wouldn't ever recommend that for production environments To remove the issue we installed the 'Session Handler Database' module and this fixed it. 1 Link to comment Share on other sites More sharing options...
gebeer Posted April 18, 2015 Share Posted April 18, 2015 I just noticed that I get the error on my vagrant box with latest stable 2.5.3. The error was related to wrong apache user/group in my vagrant box and previously I had solved it like this. But dev versions 2.5.26 and 2.5.27 don't throw this error anymore. Link to comment Share on other sites More sharing options...
watertower Posted October 7, 2016 Share Posted October 7, 2016 (edited) On 3/1/2015 at 9:14 PM, guy said: To remove the issue we installed the 'Session Handler Database' module and this fixed it. Expand Couple questions: "Session Handler Database module" is this one: http://processwire.com/docs/security/sessions/ yeah? I have the problem listed here. I cannot login to admin section. How can I install a module without using admin interface? ***UPDATE*** I could not log in because the session.referer_check in php.ini was set to the wrong domain. Edited October 10, 2016 by watertower Resolved! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now