Wedge

It certainly feels a bit more natural, especially with the quick edit button there as well. Though having quite a dark line either side of it does break up the post + action bar + signature a bit much.

The problem with the checkbox where it is right now, it seems like it's just random and out of place.

Because it's still the same basic problem, regardless of whether you use FTP or SFTP.

Scenario 1: the www-data user owns the files. They're writable from Wedge. They're also writable by definition from ANYTHING ELSE that's web-based on the server. That means any rogue process can infect any Wedge file or plugin file with code. This, really, is the risk vector that we're talking about.

Scenario 2: the proper user account owns the files. Then they make everything 777 (and experience says they won't put them back to 644), so Wedge can write the files. Same problem: they're still writable by any other code that's executed via PHP from web requests, which will all be run as www-data.

Scenario 3: we do it as I'm thinking, with FTP. That means we upload it to the server or otherwise obtain it, it'll be in a temporary folder somewhere. Exactly where is irrelevant, because however we get it, the same thing has to occur: it goes to a temporary place. Here's where it gets complicated: whatever we do, we really then have to get into unzipping that file. [1] Whatever we do, we've unpacked the file and we then have to upload it file by file over FTP. For any sizeable package, this is not going to be a quick process, especially if we're talking about a major upgrade. It's likely to then fall foul of the 30 second timeout, amongst other things.


These are the alternatives as I see them, and I don't like any of them that much :/

1.	We end up dumping it all into system-wide temporary folder, where it's also at risk, though there's no guarantee the files will actually be left available over any period of time. It's really a side concern though.

Well, mostly. There's already a list of boards built for id_board IN (...) that makes query_see_board. That array of boards itself is actually cached too in Load.php, meaning that you only need to update that array so that it's never allowed in the first place in that list, if that makes sense.

I know sites that have hundreds of boards, though it is certainly rare.

But if the test is integrated into the underlying list of boards to exclude before it's turned into SQL, it should be OK.

Do you know why you never had a problem with them?

Only if the server is UTC. It just returns the system time, really.

Did you ever do automatic updates for SMF?

How many people are screwed because automatic updates don't work for them? (The number of 1.1.11 updates that failed was pretty vicious, btw)


Note that if someone can show me a robust method for doing it that doesn't require making things insecure by default, I'm more than willing to entertain the idea. But the sheer mechanics of doing it considering the usual mess that is hosts + permissions means I'd rather avoid it entirely, just because that's actually better for the user.