this request was aborted because it appears to be forged

[March 9]

Has anyone a solution for this problem using Amazon web services?  I have an EC2 that is giving me trouble with this error.  I have given permissions to assets and config.php file but the problem persists.  Thanks for any help here.  

[March 9]

Thanks Alanfluff for Solved with 777 on the sessions folder and all contents.  This solved our login issue.  

[Jozsef 32]

I just came across with this topic and wanted to share my experience.

The problem with permissions is simple:

The Apache user (see: PHP) has no permission on files we upload with our FTP user and the same goes the other way around too. 

On shared hosting the solution for us was to change PHP to run as fastCGI instead of as Apache module.

This way you can upload files via FTP, leave permissions as the recommended 755 and 644 and php will be able to happily write those files/folders.

Also, you can edit/delete files and folders via FTP even though they were created by PHP.

On my VPS running Webmin I just make sure that I upload files with the virtual host user and not with the root user.

I hope it helps to sort the cause of the problem and not just treating the symptom. 

[mindplay.dk 292]

I just ran into this issue, and it was not a permissions problem.

This was a site I have checked into source-control (Git) and the problem was, some folders are exempt from source control, namely "cache", "logs" and "sessions" in the "assets" folder.

Apparently, PW will silently fail when these folders don't exist and can't be written to.

Shouldn't it should throw an exemption on failure to write to any of these folders?

The error message given currently is misleading more than helpful.

[WillyC 736]

u message cumes frm.sessions dir.

but i delete /site/assets/sessions/ and ,it remake.it

     no error

mabe u /site/assets no writtable ?

i testted w/vershion 2.5.21 for.my

grndmoms nudist marchingband.site

  mabe u need.upgrade ?

[David Karich 202]

I have the same problem with the current dev version 2.5.26 and was not able to login. I've noticed that it was the version of PHP 5.6. With PHP version 5.5 it works.

[skadoosh.nu 0]

Check permissions (chmod) and owner (chown)

[Sergio 609]

I'm running a vagrant box with nginx and varnish and got this same problem. All folder on 777.

The problem was that in the Varnish `default.vlc` I was disabling cookies from the admin url (/processwire). I commented the line and restarted the service and it worked.

[erikvanberkum 30]

I just had this issue, the problem was caused by a full hard drive. 

[caffeineben 2]

This issue was happening to me all of a sudden. Happened just after uploading a 3MB photo via the admin.  Tried messing with permissions and no help. Tried deleting the photo via FTP and suddenly was able to login again. Uploaded another photo and got the "appears to be forged" warning. Then it occurred to me that possibly I had maxed out my allocated storage. This was the case.  I increased my space on my hosting account and everything is good again.

[B3ta 4]

On 4/24/2017 at 8:40 AM, erikvanberkum said:

I just had this issue, the problem was caused by a full hard drive. 

I had my hard drive full and clearing the servers /temp folder solved the issue.

[rastographics 14]

I'm having this issue after moving to production.

I'm hosting on a Linux web app on Azure.

All permissions are set as rwxrwxrwx for all folder and files in the webroot.

I have plenty of free space.

I tried deleting the site/assets/sessions directory...a new one gets created properly automatically upon next sign in attempt.

Session files are being created in the site/assets/sessions directory, so I know that processwire is able to access that.

 

What else could be the issue if it's not permissions or storage space?

[Pixrael 199]

16 minutes ago, rastographics said:

I'm having this issue after moving to production.

I'm hosting on a Linux web app on Azure.

All permissions are set as rwxrwxrwx for all folder and files in the webroot.

I have plenty of free space.

I tried deleting the site/assets/sessions directory...a new one gets created properly automatically upon next sign in attempt.

Session files are being created in the site/assets/sessions directory, so I know that processwire is able to access that.

 

What else could be the issue if it's not permissions or storage space?

check this, I experience that before:

 

[rastographics 14]

@Pixrael I'm not very experienced with linux but I thought that if PW is creating new files in site/assets/sessions directory, it has permissions to write there? Or is the php session path a different thing than the PW session path?

[rastographics 14]

The following is my session.save_path from phpinfo().

 

I found someone who showed how to change the session.save_path with this code:

session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));

But that didn't seem to make any difference.

 

[rastographics 14]

I changed my .htaccess file to successfully get the session.save_path to change to a local directory that I am sure I have full ownership permissions on:

 

 

I restarted the site, cleared all cookies, and still get the error. Any ideas?

[Pixrael 199]

Try to change it in the PHP settings: https://stackoverflow.com/questions/8927404/how-to-change-session-save-path-in-php-ini-file

[rastographics 14]

I tried the methods in that stackoverflow question and they did not work. As you can see in my posted screenshot, I was able to get phpinfo() to recognize a different save_path by using .htaccess. However that did not keep the "appears to be forged" error from showing up when logging in.

 

The app is using the docker configuration based on standard php apache image as seen in this repo:

https://github.com/Azure-App-Service/php/tree/master/7.2.5-apache

 

Please if anyone has any other ideas of what can be keeping me from logging in, this is preventing us from bringing our ready website to production. Thanks!

[rastographics 14]

I also changed the permissions of the /tmp folder to 777 just to see if that would fix it. Still not working.

[rastographics 14]

In site/config.php if I set:

$config->protectCSRF = false;

Then 3 different things happen:

A wires_challenge cookie is now showing up in my browser (wasn't there before.)

The error "appears to be forged" no longer shows up.

?login=1 is added to the url string

Still does not login

[rastographics 14]

Installed fresh processwire from scratch on identical hosting setup.

When going through installer, everything checks out as normal, except on the final review page after install, these errors appear:

 

 

I can still continue on to login page, but original error is still present and prevents login.

[BitPoet 2,095]

Take a look at the raw http response body in your browser's developer console. My guess is that some kind of error/warning output from PHP (perhaps a configuration conflict in php.ini or a PHP version issue) performs some early output and thus prevents sessions and login from working. But the raw response should contain some kind of hint about it.