This request was aborted because it appears to be forged

[Gazley]

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.

[WillyC]

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

[Gazley]

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.

[pwired]

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 work
3. try to set /site/assets/ to 777 and recursively all inside /site/assets/,

[pwired]

Try to replace your index.php file with one from the dev branch and see if that works.

[Gazley]

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!  

[SiNNuT]

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

[Gazley]

Hi SiNNut,

Yep, it's an Ubuntu server. Thanks very much for the link

[OrganizedFellow]

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.

[LostKobrakai]

@OrganizedFellow

Maybe just exclude contents of those folders, so the folders themself get pushed to your git server.

[Nico Knoll]

Scroll down a little and try the tricks on this page: http://processwire.com/docs/tutorials/troubleshooting-guide/page2

[drpuff]

@OrganizedFellow

Yes, same here. This worked for me too....along with a quick change of .gitignore!

Thanks.

[shamus]

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

[guy]

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.

[gebeer]

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.

[watertower]

On 3/1/2015 at 4:14 PM, guy said:

To remove the issue we installed the 'Session Handler Database' module and this fixed it.

Couple questions:

1. "Session Handler Database module" is this one: http://processwire.com/docs/security/sessions/ yeah?
    
2. 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!