Jump to content

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


debbylevinson

Recommended Posts

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!

Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 6 months later...

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.

Link to comment
Share on other sites

  • 2 weeks later...

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

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

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 by alan
Found answer (Like DUH).
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by watertower
Resolved!
Link to comment
Share on other sites

  • 5 months later...

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

 

Link to comment
Share on other sites

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...:(

 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
}

 

Link to comment
Share on other sites

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>

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...