Wedge

No, it's the server's timestamp. i.e. it's however many seconds since 1/1/1970 relative to the server's timezone. Super happy fun times.

Does it? I've not noticed any other problems since then.

This seems to be fixed now Nao has altered the code, and I've certainly not seen any problems since :)

No, because the system's clock will update with its local timezone rules, so you have to get that right, otherwise you'll get DST applying at times you have no knowledge of whatsoever.They don't. You certainly could do it yourself, if you knew the timezone the post was written in, but that means storing it per post and doing extra calculations to do it. But for the extra hassle, it seems... overkill.

Because just about every system ever designed to do that has to make the files writable to the webserver. Which means making everything 777. Or you fuck around with creating a manual S/FTP connection, unpacking the update file by file and uploading it via S/FTP that way. While the latter is feasible for plugins, it simply isn't feasible for large-scale updates. And that still assumes the system is actually running FTP or SFTP, systems like IIS won't be. (And believe me, getting it running properly on there is a nightmare)

So if you don't fuck about with S/FTP, you tell people how to chmod or chown (and just look at how many support topics there are on SMF for this) their files, and once it works, they're not going to put it back to secure afterwards.Isn't going to happen. You'll always have people who won't upgrade because they've made custom changes they won't upgrade for, or because they think that their plugins won't work.

But, it's interesting to note that the systems that have one-click updates are more routinely victims of server abuse through files being infiltrated (because of poor permissions setup) than those that don't.

Even putting aside these factors, you're left with an update system that makes the files insecure by default, or an update system that is secure by default but requires users to do some work to keep it up to date. I'd certainly prefer the latter, especially as updates should just be a case of uploading a new set of files, nothing more.

Then you need a bigger stick with a sharper point on it, I didn't notice it :hmm:

I'm not excited, the whole concept is fundamentally flawed.

Maybe when IPv6 is widespread and everyone's using it we can reconsider it but there are so many foibles attached to using IP as 'detection' that it's unreal.

* there are still users shuffled behind a massive network so that they have different IPs over time, sometimes per page, though this is distinctly less common than it used to be.
* users behind any kind of proxy will be lumped together under fewer IPs, meaning that for example the one forum I work on will only ever show 1 guest because of way requests are routed to it behind the firewall, it only ever sees 10.0.0.2 as the incoming IP address. EVER. Kind of renders everything else moot for that user.
* it still treats different Google (+Bing+Baidu) bots as separate users.
* spammers can and will inflate this artificially.
* mobile users are still likely to be incorrect, especially if they happen to be on the move between cell towers, again it's routed through a proxy, though a much larger one.

IP != identification of any kind.That's where it gets complicated. If we don't track sessions for guests, they can still log in, with the session and cookie generated after successful authentication. All we lose at that point is the ability to validate that they came from an existing page to log in (but that's not really a massive prevention layer)

As far as handling failed logins and preventing more than 3, that would have to be done in a session but there's no reason we need to start sessions all the time for every user/guest/wandering monkey, which is where I'm going with this.


Though, disregard the whole cookie aspect. For the purposes of what I'm suggesting, the fact that cookies are used is almost irrelevant; the fact we're doing sessions at all for guests outside of logging in is a massive amount of per-request overhead that I don't think we need to handle since all we're actually doing in those cases is analytical stuff and vague storage.

What, exactly, do we need to store in the session regarding mobile detection?

The IP address used is the one the webserver itself received - if it's behind a firewall it might be the internal IP rather than an external one. It's... complicated.Thanks, though I really wanted a link so I could see them in action before I looked at any code. It's not always practical to study code to see the result you will get from it ;) Still, always good to have the code handy.