Jump to content

This request was aborted because it appears to be forged


Gazley
 Share

Recommended Posts

Hi there,

I've just received notification that a user trying to login to a site is getting the above message. I've viewed a number of threads in the forum about this error message but I can't seem to see a comparison. The logins to the site have always been OK and I have made no changes recently. Logins were working fine and suddenly, overnight, this error is being raised.

I can't access the site right now because I'm away from my dev box. I just thought I'd ask if anyone has a view on what kind of things might have changed on the server for it to start raising this error?

Many thanks.

Link to comment
Share on other sites

Hi WillyC

Thanks for the heads-up. I've tried logging on myself from a different browser, different machine and I get the same issue on any login that I try?

I'll keep working on the beard too ;)

Cheers.

Link to comment
Share on other sites

Check your web host what they recommend for their server-writable directory permissions,

1. is your /site/config.php readable ?
2. 644 on config.php and 755 on /site/assets/ should normally work
3. try to set /site/assets/ to 777 and recursively all inside /site/assets/,

Link to comment
Share on other sites

Hey Guys,

Thanks for the great tips and advice around this. I came across this: https://processwire.com/talk/topic/1563-this-request-was-aborted-because-it-appears-to-be-forged/?p=46616

I checked out the disk size and sure enough, it was out of space! I resized the drive and the problem immediately went away. 

We've just enabled secure login so that users can view their own galleries and the session cache was choc full of expired sessions. I assumed that PHP would remove the sessions once they expired but clearly, this isn't the case. Is there any particular guidance around the removal of session files?

Anyway, problem solved - thanks again! :) 

Link to comment
Share on other sites

PW should and would remove stale session files. In some cases this so-called garbage collection does not work, especially on Ubuntu servers. Adding a couple lines of PHP to config.php solves this problem for most people. more info here: https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/?p=56596

  • Like 7
Link to comment
Share on other sites

  • 5 months later...

Had this error also.

I'm using OpenShift with 1 gear as my development server. It's some good practice with GIT :D

I SSH into my server and noticed that /site/assets/cache, logs, and sessions JUST DID NOT EXIST.

Totally weird, right?

Well, not totally.

I had them listed in my .gitignore file. I read elsewhere on the forums that they should be added.

So I had originally created/installed PW on my local machine and when I pushed the master UP, of course, cache logs and sessions didn't work. So I manually recreated them and so far ... yeah, it's working fine.

OH, version 2.4.18 dev.

Link to comment
Share on other sites

  • 4 months later...
  • 2 weeks later...

I have already replied to a related post by Joss (https://processwire.com/talk/topic/8672-forged-again/) but I just came across this topic and seems there's been a lot more discussion here regarding this "forged request" issue. 

Anyways, I'm running PW 2.5.3 and am experiencing the dreaded "TemplateFile: This request was aborted because it appears to be forged." error described herein while trying to log into the admin interface AND using a mobile device running iOS.   I have tested the admin login successfully using droid mobile devices (both phone and tablets) , along w/ most desktop browsers including IE8-11, FF29+, and most recent Opera and Safari versions.

Curious if anyone has experienced the same thing w/ iOS 7 and has a recommended fix?

Note: since find this post, I have tried using Nico's tips in his troubleshooting guide regarding altering CSRF config settings (e.g. $config->protectCSRF = false;$config->sessionChallenge = false; $config->sessionFingerprint = false;).  

After integrating these changes, this resulted in my login request being bounced back to admin login form, without any error (and failed login).   

------------ PLEASE IGNORE:  FIXED ----------------------------------

Cookies must be enabled...had wrong settings.

Edited by shamus
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

To add to the above:

We experienced this issue with an established site when moving from http to https.

Login requests either threw this error or simply returned you back to the login screen after silently failing.

Following trying all the suggestions posted by Nico - apart from /site/assets/ chmod 777 - as he mentions wouldn't ever recommend that for production environments

To remove the issue we installed the 'Session Handler Database' module and this fixed it.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
  • 1 year later...
On 3/1/2015 at 4:14 PM, guy said:

To remove the issue we installed the 'Session Handler Database' module and this fixed it.

Couple questions:

  1. "Session Handler Database module" is this one: http://processwire.com/docs/security/sessions/ yeah?
     
  2. I have the problem listed here. I cannot login to admin section. How can I install a module without using admin interface?

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

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
 Share

  • Recently Browsing   0 members

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