20 replies to this topic

[joshuag]

Hi,

I just moved PW to a new server and now I can't login because I am getting the error:
"this request was aborted because it appears to be forged" when submitting the login form.

I tried changing the password and username with the API... thinking this is session related?

Any suggestions?

Thanks in advance,

[joshuag]

ok fixed this. It was permission problem... (smacks head.)
had to make sure /site/config.php was readable.

Clear case of the mondays.

[Martijn Geerts]

I like these posts, clear titles, quick answers.

[SiNNuT]

I like these posts, clear titles, quick answers.

especially when someone answers their own question

[onjegolders]

I've just transferred a site from localhost to a live domain and I'm having this exact same problem. Think my permissions on config.php are fine. Can someone confirm what they should be? Thanks

[onjegolders]

Just managed to get in by changing permissions on the assets folder to 777. Not sure how much I fancy leaving it like that but for now will have to do as putting it back down to 755 for example, I get the error message again.

[DaveP]

Don't know what they should be, but just looking at a couple of live sites they are 644 on config.php and 755 on /site/assets/.

[ryan]

Just managed to get in by changing permissions on the assets folder to 777. Not sure how much I fancy leaving it like that but for now will have to do as putting it back down to 755 for example, I get the error message again.

Most likely Apache is running as the same user for everybody on the server, probably with a name like "nobody". So it's not going to be able to write to a directory that is only writable to you (755)... it'll only be able to read from it. If the accounts a truly jailed from one another, and one account can't manipulate the files of another (by way of Apache) then 777 should be no problem. Likewise if it's a dedicated or VPS without untrusted accounts on it, then it should be fine. It sounds like that's the only way it'll run right now, so I would set it to that and then check with the web host what they recommend for Apache-writable directory permissions, and do what they suggest. You might also inquire if you can get an suPHP environment, where Apache/PHP would run as your account--in that case, you would only need rwx to yourself (700) or writable to you and rx to others (755).

[alanfluff]

Same here: I moved a site to a safe live hosting env' and had this error.

The fix proved to be making /site/assets/ 777 and recursively applying that to all inside /site/assets/, that fixed it thanks posters.

[Pete]

I've had two lots of hosting where I asked the host to switch it to suPHP - there are only a few minutes of downtime during the process, if that, and the permissions side of things suddenly makes infinitely more sense, so +1 to ryan.

[evanmcd]

I just got this error too, but found that it persisted even after I double-checked my assets and config.php permissions.

I had installed the site using the ProcessWire Blank Profile, so figured I'd try it without that. Not sure why, but it did the trick. Removing the current install and reinsalling while sticking with the default site cleared up the issue.

[Martijn Geerts]

"this request was aborted because it appears to be forged" message is also shown when try to login and cookies are disabled.
(Somewhat confusing, better to get a message to enable cookies before tying to login)

[cstevensjr]

I just got this error too, but found that it persisted even after I double-checked my assets and config.php permissions.

I had installed the site using the ProcessWire Blank Profile, so figured I'd try it without that. Not sure why, but it did the trick. Removing the current install and reinsalling while sticking with the default site cleared up the issue.

I just ran into the exact same problem trying to use the Blank Profile.

[antknight]

I just ran into the exact same problem trying to use the Blank Profile.

Same for me

[Soma]

Blank profile is done using pw 2.2.0 I think so there could be the problem. However it would take u only little time creating a new one. Or just start with the default install, which is actually very nice start.

[antknight]

Is it OK to just use the default install and just delete the fields, pages and templates? Anything else that should be done?

[Soma]

Nope. But i pefer to use the fields and templates as a start so never ever do it. :-P

[ryan]

Is it OK to just use the default install and just delete the fields, pages and templates? Anything else that should be done?

This is perfectly fine. I think that's what most people do. Though those fields, pages and templates are the bare minimum foundation for nearly any site I build, so it's rare that they get deleted here. I guess you could say that the default profile is the blank profile for some of us.

[Georgson]

Just managed to get in by changing permissions on the assets folder to 777. Not sure how much I fancy leaving it like that but for now will have to do as putting it back down to 755 for example, I get the error message again.

 

Same for me here... I don't know why that happened. Seemes to me like it has got something to do with the rights of my ftp-account - because this error popped up after I created a single ftp-account for the new pw-directory - rather than using one global ftp-account for all directories.

 

Anyone got a solution here? Cause I feel quite uncomfortable having site/assets/ on 777... 

[ryan]

Anyone got a solution here? Cause I feel quite uncomfortable having site/assets/ on 777... 

 

Is it a shared hosting account, or a dedicated/vps? If it's some kind of dedicated platform where you don't have other accounts under someone else's control, then it's not as much of a concern. But I think this is a question for your hosting provider. What's probably happening is that PHP can't write to /site/assets/. Who is listed as the directory owner? It's most likely you, which would mean that Apache is running under an account other than yours that does not have write access. I would check with your hosting provider to see what permissions they recommend for CMSs that need to have a writable directory. This can very from host to host, so it's tough for us to narrow in on it here short of trying different options (that are more secure than 777) till it works.