Can't login to existing Processwire site

[landitus]

Hi all!

I have a site with PW running just fine for some time now, but today I can't login. I put my credentials and there's no error, just the login form reloaded. I used other user's logins and the same happens.

Where should I start looking to fix this? I have access to the server (obviously) but not total control over it. Maybe there's something in the server that triggered this.

I've read some topics about this and there's no sessions log files to erase (as some suggested). My concern is that I haven't updated this site or changed any file via FTP for some time, just regular PW powered backend editing. I'm using PW 2.1, btw.

thanks a lot!

[AnotherAndrew]

Did your try yoursite.com/processwire/? Or did you change the login to something else?

[landitus]

Did your try yoursite.com/processwire/? Or did you change the login to something else?

Yes, I'm using the stardard url.

[teppo]

Sounds strange.

I'd start by checking that ownership of and (write) access to /site/assets/ (and especially /site/assets/sessions/) are defined correctly; naturally these shouldn't just change overnight, but it's still possible that there's something strange going on at the server.

Setting chmod of /site/assets/sessions/ to 777 should confirm whether this is the cause - though I definitely wouldn't suggest leaving it like that for any longer than absolutely necessary..

Also: is PW writing anything into it's own error log (/site/assets/errors.txt)?

[landitus]

Sounds strange.

I'd start by checking that ownership of and (write) access to /site/assets/ (and especially /site/assets/sessions/) are defined correctly; naturally these shouldn't just change overnight, but it's still possible that there's something strange going on at the server.

Setting chmod of /site/assets/sessions/ to 777 should confirm whether this is the cause - though I definitely wouldn't suggest leaving it like that for any longer than absolutely necessary..

Also: is PW writing anything into it's own error log (/site/assets/errors.txt)?

Thanks Tepo! setting chmod of /site/assets/sessions/ to 777 allowed me to login again. The permissions where set to 755 both for assets and permissions folder. Now, you said it's a bad idea, right? What should I do next?

[teppo]

Glad to hear that helped!

Chmod 777 can be a security risk, depending on your host and it's configuration (especially if it's a shared host), because that basically allows all users to write and execute stuff from this particular folder. I'd suggest at least setting it to something like 750 and changing owner of the folder to whatever user your scripts are executed as (chown.) If you're unsure which user that would be, this is one way to find that out: http://www.davidmorison.com/node/23.

.. and if someone reading this has more knowledge about this subject, please share! I'm definitely not a Linux guru, just trying to follow the principle of least privilege combined with some common sense here

[ryan]

Whether 777 is a bad idea or not depends on several factors like whether it's a shared host, and if so, how well the accounts are jailed from one another. I think that many shared hosts are pretty well jailed against problems here now, though that didn't used to be the case. So you have to be careful and critical about your web host in this area. If you are on your own server (VPS or dedicated) and your site(s) are the only ones running there, then it's a non issue.

The problem with both 777 and 755 is that even if the accounts are jailed at the shell/FTP level, if Apache is running as the same user (like "nobody", as it does on my server) then a PHP script on one account can write a file to another account anywhere that the other account has an Apache-writable directory. 755 doesn't really help you here (I don't think) because so long as Apache can write to it, the problem is the same. I don't have enough experience with other shared hosts to say how good protection is for that problem. Even if the problem exists, chances are you won't ever have to deal with the consequences as exploiting it can be rather obscure, but it's always a real risk.

Consider another risk with shared hosts-- readable files aren't any safer. Another account could create a PHP script that reads a file containing your DB connection info, then connect to the DB and have full read/write access to your database.

I think it's best to use a VPS, dedicated or something like it so that you have a completely separate OS instance from any other accounts, and that ensures you can have an Apache readable/writable directory without worrying about other accounts taking advantage of it. Another route is using a server that runs Apache as a CGI or phpsuexec so that all scripts execute as you rather than Apache. In such a case, you would remove read and write access from everyone except yourself, providing a little more security in a shared hosting environment. But shared hosting is not worth the hassle and cost savings in my opinion.

[teppo]

Thanks for the clarification, Ryan! I didn't realize shared hosting had so many underlying problems (and thankfully I don't have to deal with those when it comes to client projects..)

[landitus]

Thanks for all the replies! Sadly many clients use shared hosts, but well, I'm not in charge of them, but now I can advise them based on Ryan's great answer.

[ryan]

A lot of shared hosts will have Apache/PHP running as you, which is good. When you installed ProcessWire on your server, if it never asked you to make any directories writable, then Apache/PHP is likely running as you. You can also tell by running a PHP script that just contains this:

<?php echo exec('whoami');

If you run that script and it says the name of your account, then there's likely not any reason for anyone to have access to the site's files except you. This may or may not be necessary, depending on what jailing measures your shared host is already handling. But better to be safe than sorry. Don't do any of this if Apache/PHP is not running as you. To start, you can recursively remove write access to your /site/assets dir:

chmod -R og-w site/assets

Likewise, remove read access from your /site/config.php:

chmod og-rw site/config.php

You'll also want to tell PW what permissions to use when creating new files or directories. So edit your /site/config.php and locate the lines containing the chmodFile and chmodDir settings. Update them to this:

// 0755 = owner r/w/x, group+other can r/x

$config->chmodDir = "0755";

// 0644 = owner can r/w, group+other can only read
$config->chmodFile = "0644";