HEEELP! This request was aborted because it appears to be forged!

[szabesz]

6 minutes ago, Pixrael said:

I read each of them, almost all with different situations/solutions (session.referer_check in php.ini, no space in server disk, file permissions, CSRF, database auto_increment, etc), with all in the forum trying to guess the solution, even some threads don't reach a final solution

So you can see that it is a server environment issue and a ProcessWire one, ie. both. That is why it is hard to track down.

Edited April 5, 2018 by szabesz
trying to clarify what I mean :)

[Pixrael]

I know, I know. I don't want to be misunderstood here, I love PW .. but I don't like so much the look my boss has in his eyes now .. hehe

[flydev]

It was a server issue and not a ProcessWire one - the reason behind the message "This request was aborted because it appears to be forged" on this case was because the PHP session path was not writable. The website is back online with backend working like a charm  ?

[bernhard]

Great that you found the issue. Would be curious what WordPress would have done on that server ? Do you think it would make sense to improve processwire so that it showed an appropriate error message in such cases? Would that be even possible? If yes maybe someone can make a PR? ☺

[flydev]

I think it could be checked on the installation process, checking if these path are writable or not and thus sending a warning that potential session issue could arise.

 

5 minutes ago, bernhard said:

Would be curious what WordPress would have done on that server

I can't tell you, I think nothing, but I never tried to install this CMS ?

[szabesz]

Just now, flydev said:

it could be checked on the installation process

+1  And in the cases of migrating a site to its new home, one should always install a clean ProcessWire instance in advance in order to test that the server environment is OK to begin with.

[kongondo]

1 hour ago, flydev said:

on this case was because the PHP session path was not writable.

Excellent work on solving this! I am curios though, how would upgrading MySQL cause this? It seems the site was working OK pre-the upgrade.

[flydev]

The reason, after the upgrade of Plesk and PHP, by default the PHP setting session.save_path point to /var/lib/php/session and not /var/tmp where before he got r/w permissions (I don't know if Plesk was already installed or not before the upgrade). The final problem was not MySQL.

[Pixrael]

8 hours ago, kongondo said:

Excellent work on solving this! I am curios though, how would upgrading MySQL cause this? It seems the site was working OK pre-the upgrade.

If you check this tutorial https://support.plesk.com/hc/en-us/articles/213367429-How-to-upgrade-MySQL-from-5-1-to-5-5-on-Linux, you can see a note that says "The PHP package can also be updated during this procedure". I did not pay attention to this because I had installed the latest version of PHP, but it seems that anyway the package and its configuration were changed during the upgrade.

9 hours ago, flydev said:

I think it could be checked on the installation process

maybe.. and during the user login at admin too.. because like in my example, it can happen after the installation...

At least we need a topic, or a recipe at https://processwire-recipes.com/ or wherever the option we have, to guide beginners like me. Explaining all the test that must be done after "This request was aborted because it appears to be forged" because after my investigation I found several causes for this, and almost 127 forum entries about it.

https://www.google.com/search?q=site:processwire.com+"This+request+was+aborted+because+it+appears+to+be+forged"

Now, at this moment I can breathe! I want to say a BIG THANK YOU to @flydev who won my admiration and has been a wonderful human being

[bernhard]

I think you could open an issue at GitHub explaining your example and providing the link to the 127 entries related to that error message. Maybe Ryan has an idea how he can add some checks that show more helpful informations and make it easier to track down the issue.

[Testic]

In my case, sessions were not handled correctly. 

In order to fix it:

1. I installed the core module Session Handler Database (SessionHandlerDB) locally,
2. Create a mysqldump of my local database 
3. Imported the mysqldump to my online environment 
4. Voila! 

[Mikie]

In my case, installing a module with the same class name as a personal module I had been working on broke my site.

Wiping the site/assets/cache and session files and removing the offending module folder didn't work, so I emptied the caches database table.

This restores access to the admin, however I then get a bunch of errors about Inputfields not existing like the screenshot in the original post in this topic. If I then refresh my modules the site breaks again with a specific "Class not found" error.

The fix is to re-order the offending modules declared in the Modules.site/modules/ row of the caches table in the database, as explained here:

Regarding "This request was aborted because it appears to be forged!", the only time I have seen that was when I was on a load balanced internet connection, eg a router splitting access to two WANs. I hadn't configured the router to keep individual local ips on the same connection, and thus it kept switching my computer's public ip and the only reason I figured this out was 1. processwire 2. banking websites!