March Posted December 2, 2014 Share Posted December 2, 2014 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. Link to comment Share on other sites More sharing options...
March Posted December 2, 2014 Share Posted December 2, 2014 Thanks Alanfluff for Solved with 777 on the sessions folder and all contents. This solved our login issue. Link to comment Share on other sites More sharing options...
Jozsef Posted January 25, 2015 Share Posted January 25, 2015 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. 1 Link to comment Share on other sites More sharing options...
mindplay.dk Posted March 4, 2015 Share Posted March 4, 2015 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. 1 Link to comment Share on other sites More sharing options...
WillyC Posted March 4, 2015 Share Posted March 4, 2015 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 ? 2 Link to comment Share on other sites More sharing options...
David Karich Posted April 16, 2015 Share Posted April 16, 2015 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. 1 Link to comment Share on other sites More sharing options...
skadoosh.nu Posted April 21, 2015 Share Posted April 21, 2015 Check permissions (chmod) and owner (chown) Link to comment Share on other sites More sharing options...
Sergio Posted June 17, 2015 Share Posted June 17, 2015 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. Link to comment Share on other sites More sharing options...
erikvanberkum Posted April 24, 2017 Share Posted April 24, 2017 I just had this issue, the problem was caused by a full hard drive. Link to comment Share on other sites More sharing options...
caffeineben Posted June 14, 2018 Share Posted June 14, 2018 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. 2 Link to comment Share on other sites More sharing options...
B3ta Posted June 26, 2018 Share Posted June 26, 2018 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. 1 Link to comment Share on other sites More sharing options...
rastographics Posted October 4, 2018 Share Posted October 4, 2018 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? Link to comment Share on other sites More sharing options...
Pixrael Posted October 4, 2018 Share Posted October 4, 2018 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: Link to comment Share on other sites More sharing options...
rastographics Posted October 9, 2018 Share Posted October 9, 2018 @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? Link to comment Share on other sites More sharing options...
rastographics Posted October 9, 2018 Share Posted October 9, 2018 The following is my session.save_path from phpinfo(). I found someone who showed how to change the session.save_path with this code: session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session')); But that didn't seem to make any difference. Link to comment Share on other sites More sharing options...
rastographics Posted October 9, 2018 Share Posted October 9, 2018 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: I restarted the site, cleared all cookies, and still get the error. Any ideas? Link to comment Share on other sites More sharing options...
Pixrael Posted October 10, 2018 Share Posted October 10, 2018 Try to change it in the PHP settings: https://stackoverflow.com/questions/8927404/how-to-change-session-save-path-in-php-ini-file Link to comment Share on other sites More sharing options...
rastographics Posted October 10, 2018 Share Posted October 10, 2018 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! Link to comment Share on other sites More sharing options...
rastographics Posted October 10, 2018 Share Posted October 10, 2018 I also changed the permissions of the /tmp folder to 777 just to see if that would fix it. Still not working. 1 Link to comment Share on other sites More sharing options...
rastographics Posted October 10, 2018 Share Posted October 10, 2018 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 ? Link to comment Share on other sites More sharing options...
rastographics Posted October 10, 2018 Share Posted October 10, 2018 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: I can still continue on to login page, but original error is still present and prevents login. Link to comment Share on other sites More sharing options...
BitPoet Posted October 11, 2018 Share Posted October 11, 2018 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. Link to comment Share on other sites More sharing options...
benbyf Posted July 29, 2020 Share Posted July 29, 2020 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. Link to comment Share on other sites More sharing options...
fredbob Posted August 7, 2020 Share Posted August 7, 2020 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: 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. Link to comment Share on other sites More sharing options...
vmo Posted October 7, 2020 Share Posted October 7, 2020 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now