Request seems to be forged

[MichaMichaMicha]

Recently I set up ProcessWire for 3 environments:

- Development

- Testing

- Production

From the very beginning I've had the issue when logging in in the admin the WireException "This request was aborted because it appears to be forged." gets triggered.

I've already changed the vars in config.php:

//different for each env.

$config->sessionName = 'wireDEV';

$config->sessionName = 'wireTEST';

$config->sessionName = 'wirePROD';

$config->sessionChallenge = false;

$config->sessionFingerprint = false;

It even happened to someone that has only logged in to Production.

I'm very sure the assets folder and the config.php in the site folder both have 777 permissions recursively.

I've added phpcode to remove all cookies when the WireException triggers, that sort of seems to fix the problem, only people have to login twice to get in the admin...

Does anyone know what could be wrong?

[Ben]

As long as your environments are hitting unique server names (dev.example.com, www.example.com), I don't think session collision should be a problem.

In the login form, do you have a CSRF token (the _post_token hidden input)? Any chance you're using a custom admin theme?

EDIT: You could try another setting, in config.php:

$config->protectCSRF = false; 

It's best to leave it enabled, but it might help rule out other issues.

[Manfred62]

"This request was aborted because it appears to be forged."

sounds like the same I got, when trying to install PW with 'ProcessWire Blank Profile'. This was fixed in the newest dev version.

[interrobang]

I just moved a site from my local MAMP to the production server and could not login. I tried everything suggest here in the forum, but the "forged" message remained.

Because I did not want to upload all sessions I excluded the "/site/assets/sessions/" folder when uploading the site by ftp. As soon as I created the "/site/assets/sessions/" folder by hand on the server everything worked again.

Conclusion: Remember that you need these folders:
/site/assets/cache/
/site/assets/logs/
/site/assets/sessions/

[bitpolymerase]

Conclusion: Remember that you need these folders:

/site/assets/cache/

/site/assets/logs/

/site/assets/sessions/

Thank you for pointing this out, I have wasted hours trying to figure out the differences between the dev and production environments that was preventing admin login. For some reason git was not pushing up the /site/assets/sessions/ directory. Simply making this directory fixed my problem.

[Gazley]

Same thing for me with Git - great tips

[gebeer]

git push ignores those dirs because they are listed in .gitignore

Just came across this post trying to solve the same issue...