Jump to content

Recommended Posts

Posted

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.  

  • 1 month later...
Posted

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. 

  • Like 1
  • 1 month later...
Posted

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.

  • Like 1
Posted

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 ?

  • Like 2
  • 1 month later...
Posted

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.

  • Like 1
  • 1 month later...
Posted

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

  • 1 year later...
  • 1 year later...
Posted

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.

  • Like 2
  • 2 weeks later...
Posted
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.

  • Like 1
  • 3 months later...
Posted

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?

Posted
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:

 

Posted

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

Posted

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:

 

image.thumb.png.13d371063231b067fec5da9d24f8c583.png

 

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

Posted

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!

Posted

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 ?

Posted

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:

 

image.thumb.png.f77987a9a642d82ee7fdb38658e78e44.png

 

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

Posted

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.

  • 1 year later...
Posted

Had this issue again recently using ProcessWire 3.0.62 on shared hosting. I managed to fixed the issue with 777 on both templates and assets folders (as didnt help just on assets for some reason..?) but I'll need to go in a take a look around the hosting as this is massively not good ? Will report back.

  • 2 weeks later...
Posted
On 10/11/2018 at 5:16 AM, rastographics said:

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:

 

image.thumb.png.f77987a9a642d82ee7fdb38658e78e44.png

 

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

Did you ever work this one out?
I'm trying to run Processwire on Azure App Service (Linux), file permissions are set correct, and I have set the PHP session path.

I get the same errors on installation, then I can't looking due to the "ProcessWire: ProcessLogin: This request was aborted because it appears to be forged." error.

  • 2 months later...
Posted

Hi,
while migrating a website to a staging server ant to put the site online today i got this error:

ProcessWire: ProcessLogin: This request was aborted because it appears to be forged.

DEBUG MODE ($config->debug == true):
#0 /wire/modules/Inputfield/InputfieldForm.module(155): ProcessWire\SessionCSRF->validate()
#1 /wire/core/Wire.php(397): ProcessWire\InputfieldForm->___processInput(Object(ProcessWire\WireInputData))
#2 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___processInput', Array)
#3 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\InputfieldForm), 'processInput', Array)
#4 /wire/modules/Process/ProcessLogin/ProcessLogin.module(362): ProcessWire\Wire->__call('processInput', Array)
#5 /wire/core/Wire.php(394): ProcessWire\ProcessLogin->___execute()
#6 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array)
#7 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessLogin), 'execute', Array)
#8 /wire/core/ProcessController.php(337): ProcessWire\Wire->__call('execute', Array)
#9 /wire/core/Wire.php(394): ProcessWire\ProcessController->___execute()
#10 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array)
#11 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessController), 'execute', Array)
#12 /wire/core/admin.php(153): ProcessWire\Wire->__call('execute', Array)
#13 /wire/modules/AdminTheme/AdminThemeUikit/controller.php(15): require('/var/www/vhosts...')
#14 /site/templates/admin.php(19): require('/var/www/vhosts...')
#15 /wire/core/TemplateFile.php(318): require('/var/www/vhosts...')
#16 /wire/core/Wire.php(394): ProcessWire\TemplateFile->___render()
#17 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___render', Array)
#18 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array)
#19 /wire/modules/PageRender.module(536): ProcessWire\Wire->__call('render', Array)
#20 /wire/core/Wire.php(397): ProcessWire\PageRender->___renderPage(Object(ProcessWire\HookEvent))
#21 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___renderPage', Array)
#22 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageRender), 'renderPage', Array)
#23 /wire/core/WireHooks.php(924): ProcessWire\Wire->__call('renderPage', Array)
#24 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'render', Array)
#25 /wire/modules/Process/ProcessPageView.module(213): ProcessWire\Wire->__call('render', Array)
#26 /wire/core/Wire.php(397): ProcessWire\ProcessPageView->___execute(true)
#27 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array)
#28 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'execute', Array)
#29 /index.php(55): ProcessWire\Wire->__call('execute', Array)
#30 {main}

How can I identify the files and folders that I need to change the permissions from this?
And what might be the permissions to change to?

Thank you

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
×
×
  • Create New...