Can't log in: "This request was aborted because it appears to be forged."

[debbylevinson]

I've recently installed ProcessWire on a colleague's server, but cannot for the life of me log into it successfully; I keep getting the error message "This request was aborted because it appears to be forged."

I've tried multiple suggestions linked from this post:

• Confirming there was a /site/assets/sessions/ directory (even to the point of deleting and re-creating it by hand)
• Making sure everything in /site/assets/ was set to 777 permissions
• Adding $config->protectCSRF = false; to config.php (which brought on new failure behavior -- the login page would just reload after submission)
• Changing the sessionFingerprint value to 'false' and turning on debug mode (which yielded what's essentially this error message, modulo some variable capitalization and line number changes I'm sure are due to ProcessWire updates since that post was originally made)

Also, when I have debug mode on, I see this error in the footer:

Warning: Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (/srv/psa01/stuartdarsch.com/httpdocs/site/assets/sessions) in Unknown on line 0

The path is correct, and as I said, permissions in that directory (as well as its two immediate parents) are set to 777, so the software should be able to write to it.

Any suggestions about how to fix this are welcome. Thank you!

[pwired]

Hi,

Check if /site/config.php is readable.

Check if /site/assets/ is set recursively to 777

Recreate the following folders:

/site/assets/cache/
/site/assets/logs/
/site/assets/sessions/

Else go through these 3 posts in the forum and you will find you answer:

http://processwire.com/talk/topic/1563-this-request-was-aborted-because-it-appears-to-be-forged/

http://processwire.com/talk/topic/3970-this-request-was-aborted-because-it-appears-to-be-forged/

http://processwire.com/talk/topic/2786-request-seems-to-be-forged/

[Martijn Geerts]

I do see this message random lately. ( latest dev )

It happens, after already logged in and multiple tabs open.

A thing what possibly trigger the error message is: CodeKit.

Do more People experience this with a 'reload/inject' app ?

[Soma]

Have you tried turning off session challenge?

[ryan]

This may be a problem related to ProcessWire wanting to use files for sessions and your server configured to use memcached, at least that's what the error message seems to indicate. The dev branch version has detection for this, so you might try switching to the PW dev branch and seeing if that fixes the issue for you (I'm guessing it will). Or if you want to quickly test it, just grab the index.php from the dev branch and replace the one in your installation. 

[Martijn Geerts]

<quote>Have you tried turning off session challenge?</quote>

Then there's no problem. (I think, it doesn't happen that often at all so hard to test.)

I still do think it's related to CodeKits automatic reload.

[debbylevinson]

@ryan, you're the lucky winner! Replacing the index.php file with the one from the dev branch allowed me to log in. Thank you! (Now all I have to do is figure out how to migrate my colleague's files from his current ProcessWire installation into this one, heh.)

@soma, I did not have to try turning off sessionChallenge, because Ryan's solution fixed it, but will keep this in mind should the problem somehow crop up again in the future. And Martijn, I assume CodeKit scripts are built into ProcessWire? I didn't install anything from CodeKit on my own.

One last question, since this problem does seem to have been related to memcached: do any of you know any other places where this might trip up ProcessWire? I'm not a developer -- just someone who knows enough Unix and site coding to be dangerous -- and I have no idea how memcached works or how it might affect ProcessWire's general functions.

[ryan]

One last question, since this problem does seem to have been related to memcached: do any of you know any other places where this might trip up ProcessWire? I'm not a developer -- just someone who knows enough Unix and site coding to be dangerous -- and I have no idea how memcached works or how it might affect ProcessWire's general functions.

I don't know a lot about memcached either, but I know of others using it successfully with PW (after that change you made) and have not heard of any other issues. If you find it to be an issue, you could always switch to PW's native database-driven sessions module (included in the core).

[gebeer]

Sorry for crossposting from there.

I have the same problem on admin login on my vagrant dev box.

I went through all related posts here in the forum but couldn't find a solution.

Here's what I tried:

• First thing I grabbed latest dev branch and updated /wire and index.php.
• I checked permissions for /assets folder and content as well as config.php. All set to 777
• just to make sure, I recreated cache, logs, sessions inside assets and reapplied permissions
• I tried setting $config->sessionChallenge = false;
• I tried adding $config->protectCSRF = false; (here the login screen just reloads without showing the message)
• I'm not using blank profile
• Installed a brandnew dev version -> same problem

Turning on debugging, I get:

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/www/pwfoundation5/site/assets/sessions) in Unknown on line 0

A 0 byte session file gets created. So sessions folder is obviously writable.

jan reported the same here.

But in my case there's ample space on the dev machine and I can manually create files with content from command line inside the session folder.

Now I'm really lost and don't know what else to try.

[gebeer]

Finally was able to solve my issue. It was related to user/permissions on my vagrant box. apache was running as the wrong user. After changing that I can now login

[clsource]

Finally was able to solve my issue. It was related to user/permissions on my vagrant box. apache was running as the wrong user. After changing that I can now login

Yes I have the same Issue running the lastest dev branch.

My vagrant box was running apache as www-data (Ubuntu trusty 32)

so I changed to the current user (vagrant in my case)

in this file

sudo nano /etc/apache2/envvars

changed these two lines from this

export APACHE_RUN_USER=www-data

export APACHE_RUN_GROUP=www-data

to this

export APACHE_RUN_USER=vagrant

export APACHE_RUN_USER=vagrant

then reloaded apache config with

sudo service apache2 restart

and I could log in

[alan]

I've got a persistent case of this:

• I can login AOK if I use an incognito window
• sessions are stored in the db

I've tried clearing out my browser history, cache etc, but clearly PW is now remembering something about my normal browser and not liking it.

Is my only option to permanently change "CSRF protection" and "session fingerprints" settings (which is sad as I used to login here AOK and didn't need them changed before), or, is there something I can do on the hosting or in PW to clear out PW's memory of my browser (assuming that is the problem), as noted, I *can* login with incognito.

Thanks friends and sorry if I missed something obvious (and hope the answer helps someone else :))

EDIT

Even though sessions are stored in the PW database, I checked /site/assets/sessions and found two session files o_O Deleted them and now can login OK. Confused but happy

Edited October 6, 2016 by alan
Found answer (Like DUH).

[watertower]

On 1/12/2014 at 6:33 AM, ryan said:

The dev branch version has detection for this, so you might try switching to the PW dev branch and seeing if that fixes the issue for you (I'm guessing it will). Or if you want to quickly test it, just grab the index.php from the dev branch and replace the one in your installation. 

@ryan Where is the dev branch version these days? The link above no longer works.

[adrian]

5 minutes ago, watertower said:

@ryan Where is the dev branch version these days? The link above no longer works.

https://github.com/processwire/processwire/tree/dev

Although given the age of this post, I am not sure dev vs master will make any difference if you are having this issue on PW 3.x or 2.8.x

[watertower]

On 10/8/2016 at 10:27 PM, adrian said:

https://github.com/processwire/processwire/tree/dev

Although given the age of this post, I am not sure dev vs master will make any difference if you are having this issue on PW 3.x or 2.8.x

Darn. I am having this issue. Trying everything. My server environment is, according to the sys admin: 

Quote

behind a BigIP Networks F5 load balancer cluster. The external IP/hostname are actually on the F5, which then directs traffic to the appropriate web backend based on what's being requested. It also handles SSL and SSL enforcement (an auto-redirect to the SSL version of the page), along with attaching cache control headers if the web application doesn't set them, location-based access restrictions, and a few security duties like ShellShock protection.

I'm not sure, but the cache control headers could be confusing ProcessWire. I've turned them off. See if that helps.

Turning off the cache control headers didn't work. Would this server environment be screwing up the login?

***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!

[mr-fan]

So the nice message showed up on one of my sites, too...

- did all config stuff to false ->same result if CSRF is false no message just reloading the login screen, fingerprint and SessionChallenge no chance)

- did all files to 777 for testing (i mean all files...)

PW Version is 2.7.2

PHP Version 5.6.24

Every Domain runs in a vHost with own php.ini on this shared host - www and FTP user and group are the same....

Checked some PHP vars like max_input_vars and so on...but Frontend is running only login is failing.

phpinfo() check only strange thing that i found is:

_SERVER["HTTP_COOKIE"]

wire_challenge=lko0BUK8O8Vy.WWIfl6cVJxxxxxxxxx; wire=92fc8adbfe8486f7dee4aabdf1477a7dxxxxxxxxe

Tested from different browsers, inconito mode, different computers...

The Big Change was a infrastructure change of my hoster to a complete new system. So i had have to adapt/change DB access in config.php und use a new ftp access to change PHP files but it should all switched properly - like i wrote the frontend is running well.

Only main problem after the systemchange was a PHP warning on frontend if i put display errors on about

set_time_limit

This function was disabled in the new environment, but i think that this has no impact so far.

 

Best regards and no glue where to search...;)

mr-fan

 

[mr-fan]

Bumb....while it is kind a strange...could this "forge" testing shut down complete...?

It seems that the permission are all there, every other setting in $config don't change something...

I'm a little bit helpless - will try to build a local copy of the installation at next...

 

[szabesz]

On 3/20/2017 at 4:22 PM, mr-fan said:

So i had have to adapt/change DB access in config.php

This one sounds suspicious. Did you investigate it "in greater detail"?

[mr-fan]

There is nothing special on this point...like i wrote it was a complete system move to new servers.

So i had to change the entries:

$config->dbHost = '127.0.0.1';  //stays the same
$config->dbName = 'xxxxx';    //new db name
$config->dbUser = 'xxxxx';    //new db user
$config->dbPass = 'xxxxx';   //new pw

The old db and the old filesystem stays and is accessable via old logins.

So i have only new logins to the "live" DB and the "live" filesystem that are pointed to the Domain in a new vHost environment...

[szabesz]

I see. I was just wild guessing here, suspecting something like the system connects to another mysql server not running on the same system...  

[mr-fan]

No problem - i'm poking in the dark the whole time....so every new hint is helpful - mostly i overlook something

[mr-fan]

Now i have new news from my hoster that i have to clear here....

PHP is running on this server with the modern version of Fast CGI FPM

https://php-fpm.org/

Are there any problems or special settings that i have to look for???

Webserver is running not as the same user as www/PHP User only PHP and FTP User is the same, could this be the problem???

My local copy all worked great...i was very satisfied with the hosting until now. So i really don't wanna move the whole thing....and i don't wanna grab in the core files, but as a short solution it would be great if i could shut down this forge testing complete?

regards mr-fan

[mr-fan]

If i try to force login via API i get only:

Unable to complete this request due to an error.

 

if($_SERVER["REMOTE_ADDR"]=='xx.xx.xxx.xx'){

echo "TEST";

$config->debug = true;

$config->protectCSRF = false;
$config->sessionChallenge = false;
$config->sessionFingerprint = false;


$session->login('xxx', 'xxxx')

//$user = $users('xxx');
//$session->forceLogin($user);
//run only my ip
}

 

[DaveP]

Sounds to me like a file ownership issue.

One thing you might try is installing a PW module through Modules > New > Add module from Directory and enter a Module Class Name (eg first module in directory at the moment is 'JqueryIonRangeSlider', but you could use any). You can always uninstall it again afterwards.

The reason I suggest this is that PHP will download and install whatever module you choose. If that works, you can look via FTP and see who owns the module files that have just been installed, and compare to ownership of existing files & folders (especially of caches & suchlike). If there's a difference, then that might give you/us some clues.

<edit>Actually, try Tracy Debugger if not already installed - it is wonderful and might help sort this out too.</edit>

[mr-fan]

The PHP User and FTP User are the same and in the same group permissions 777 are tested - i can't login so i can't install anything so far...but thanks for helping.