Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
4981
Features / Re: New revs
« on February 9th, 2012, 07:27 PM »
(3 added, 5 deleted, 15 modified, 48KB)
Revision: 1307
Author: arantor
Date: 09 February 2012 18:26:21
Message:
! First draft of the moderation filters code. The UI is hardly done (the show page works, as does the actual rules engine, but that's it). There is - very temporarily, I'll note - a big scary text box without a label in Security and Moderation - Anti Spam. This textbox is simply a textbox pointing at $settings['postmod_rules'] where the actual rules are stored, just so that I have somewhere to view and edit them (and that doesn't involve phpMyAdmin and forcing a cache flush), and once the UI is working, I'll remove this textbox. This change also removes the core features page, the post moderation secondary page and most of the code relating to post moderation configuration, with the exception of the permissions, and anything related to attachment approvals. Mostly this commit is just so that I have it in SVN and can work on the rest reasonably incrementally. (All files in this commit are directly related to these things.)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Load.php
Added : /trunk/Sources/ManageModeration.php
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/Post2.php
Modified : /trunk/Sources/PostModeration.php
Added : /trunk/Sources/Subs-Moderation.php
Modified : /trunk/Themes/default/Admin.template.php
Added : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Deleted : /trunk/Themes/default/images/admin/corefeatures.gif
Deleted : /trunk/Themes/default/images/admin/feature_pm.png
Deleted : /trunk/Themes/default/images/admin/post_moderation_allow.gif
Deleted : /trunk/Themes/default/images/admin/post_moderation_deny.gif
Deleted : /trunk/Themes/default/images/admin/post_moderation_moderate.gif
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/other/install.sql
(Yes, Core Features is NOW GONE FROM SVN :D And note that this is still a WIP so things can and will change.)
Revision: 1307
Author: arantor
Date: 09 February 2012 18:26:21
Message:
! First draft of the moderation filters code. The UI is hardly done (the show page works, as does the actual rules engine, but that's it). There is - very temporarily, I'll note - a big scary text box without a label in Security and Moderation - Anti Spam. This textbox is simply a textbox pointing at $settings['postmod_rules'] where the actual rules are stored, just so that I have somewhere to view and edit them (and that doesn't involve phpMyAdmin and forcing a cache flush), and once the UI is working, I'll remove this textbox. This change also removes the core features page, the post moderation secondary page and most of the code relating to post moderation configuration, with the exception of the permissions, and anything related to attachment approvals. Mostly this commit is just so that I have it in SVN and can work on the rest reasonably incrementally. (All files in this commit are directly related to these things.)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Load.php
Added : /trunk/Sources/ManageModeration.php
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/Post2.php
Modified : /trunk/Sources/PostModeration.php
Added : /trunk/Sources/Subs-Moderation.php
Modified : /trunk/Themes/default/Admin.template.php
Added : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/ManagePermissions.template.php
Deleted : /trunk/Themes/default/images/admin/corefeatures.gif
Deleted : /trunk/Themes/default/images/admin/feature_pm.png
Deleted : /trunk/Themes/default/images/admin/post_moderation_allow.gif
Deleted : /trunk/Themes/default/images/admin/post_moderation_deny.gif
Deleted : /trunk/Themes/default/images/admin/post_moderation_moderate.gif
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.english.php
Modified : /trunk/Themes/default/languages/ManagePermissions.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/other/install.sql
(Yes, Core Features is NOW GONE FROM SVN :D And note that this is still a WIP so things can and will change.)
4982
Development blog / Re: Back in the Saddle
« on February 9th, 2012, 06:49 PM »Is it me, or is it yet another exclusive feature for Wedge when it comes to forums?
Oh, and your post mentions that I removed the Media Gallery -- only from the Core Features page, of course! The master setting is now in the Media admin menu itself, as mentioned in the changelog.
4983
Development blog / Re: Back in the Saddle
« on February 9th, 2012, 05:25 PM »Hope its easy to set up "Less than 5 posts and they all get moderated prior to release" - without going round the houses and up alleyways wearing a particular colour of underwear.
And thanks :)
4984
Development blog / Back in the Saddle
« on February 9th, 2012, 04:13 PM »
Regular readers will likely have noticed that I've been slacking for a while... life's been like that, a royal pain. But in order to celebrate getting back into the swing of things, I tackled something I've been wanting to do in SMF for years (and did begin to plan it back in 2010) - some serious automated moderation rules.
The idea is that you should be able to do things easily and conveniently and awesomely. It's still very much WIP, and those who've been following one of the other topics will get a better idea of the innards but that's not why I'm writing here.
I'm writing here because I have screenshots to show as well :D And this way it'll get a bit more visibility than it might elsewhere, which means hopefully a few more people might add their comments to this. Those who follow us on Facebook will have already had some comments from me on this.
The idea is that the system should be able to do some of the work for you, not just moderating posts based on some rules (like post counts and boards) but also on content, and I fully intend to make this even *more* powerful than it already is. But already it's powerful.
The first rule says, if the post begins with /lock and the user has the permission to lock any topic, well, lock the topic.
The second rule says, if the post contains a rude word and the user isn't an administrator, moderate the topic. That's the power we're talking about, you can do things that don't implicitly require permissions everywhere.
The last rule says, simply, if the post is made in General Discussion, moderate it. That's a very broad rule, not likely to be used in real life, but illustrative more than anything.
Notice that we have two moderate rules - this is a logical rather than a technical divide. This way, we can create many different combinations quite easily - here, it's (user isn't admin + says a rude word) OR (posting in a specific board).
I couldn't think of any better way to display it but if you have any ideas, I'd love to hear them. Meanwhile, I'm going to finish up this code (it's barely enough to actually display this!) and then get onto the create-rule UI.
Oh, and people who've read the FB post will also know that I've removed Core Features. Nao's r1304 removed the Media Gallery from being in Core Features leaving Post Moderation as the only thing there, and now, it's not there. Locally, not yet committed, I've removed most of the traces of post moderation from the system (I just need to strip out the permissions stuff where it's buried deep in the permissions system)
But that means I get to finally purge one of the most illogical parts of SMF that we inherited, and I'm glad it's finally gone. I like trimming useless code at the best of times, but this was annoying to boot :D
Anyway, this is me saying "Hello!" and getting back in the saddle to make more awesomeness :)
The idea is that you should be able to do things easily and conveniently and awesomely. It's still very much WIP, and those who've been following one of the other topics will get a better idea of the innards but that's not why I'm writing here.
I'm writing here because I have screenshots to show as well :D And this way it'll get a bit more visibility than it might elsewhere, which means hopefully a few more people might add their comments to this. Those who follow us on Facebook will have already had some comments from me on this.
The idea is that the system should be able to do some of the work for you, not just moderating posts based on some rules (like post counts and boards) but also on content, and I fully intend to make this even *more* powerful than it already is. But already it's powerful.
 |
The first rule says, if the post begins with /lock and the user has the permission to lock any topic, well, lock the topic.
The second rule says, if the post contains a rude word and the user isn't an administrator, moderate the topic. That's the power we're talking about, you can do things that don't implicitly require permissions everywhere.
The last rule says, simply, if the post is made in General Discussion, moderate it. That's a very broad rule, not likely to be used in real life, but illustrative more than anything.
Notice that we have two moderate rules - this is a logical rather than a technical divide. This way, we can create many different combinations quite easily - here, it's (user isn't admin + says a rude word) OR (posting in a specific board).
I couldn't think of any better way to display it but if you have any ideas, I'd love to hear them. Meanwhile, I'm going to finish up this code (it's barely enough to actually display this!) and then get onto the create-rule UI.
Oh, and people who've read the FB post will also know that I've removed Core Features. Nao's r1304 removed the Media Gallery from being in Core Features leaving Post Moderation as the only thing there, and now, it's not there. Locally, not yet committed, I've removed most of the traces of post moderation from the system (I just need to strip out the permissions stuff where it's buried deep in the permissions system)
But that means I get to finally purge one of the most illogical parts of SMF that we inherited, and I'm glad it's finally gone. I like trimming useless code at the best of times, but this was annoying to boot :D
Anyway, this is me saying "Hello!" and getting back in the saddle to make more awesomeness :)
4985
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 01:55 PM »
Oh please. Calling it a CMS is like calling a go-kart a car. Both do the same job but one is a shabbily built, usable but neither efficient or elegant. Or it's like comparing a basic Nokia handset to an iPhone because they can both make calls when you want more than just calling functionality.Quote It's nothing like SSI.php except vaguely conceptually.Quote Not without significant work.
OK, I'm going to reiterate a point that I think has been forgotten.
I'm not bashing WP based on what I've seen. I USE WP CURRENTLY ON TWO SITES. I know exactly what it's capable of. Anything beyond a basic blog, it just can't handle. You cannot even have a page that's visible to signed in members only without *custom coding*, and not trivial custom coding, to boot. That alone rules it out of being a good CMS.Quote So when users get hacked, I can send them your way, can I? Because you know if a Wedge install gets hacked, they feel it's our fault first and foremost and never theirs.Quote Most users do not understand what shared hosting means. And they won't listen to that warning, they'll upload and install stuff regardless - but it'll be our fault when the shit hits the fan because "[Wedge] should have prevented there being a problem" and anything else is making excuses.
There's no best answer, only a selection of varyingly-bad answers, and right now I'm just sensing that not having an upload feature (like, I'll note, XenForo and quite probably vBulletin, though I haven't used it) is actually the lesser evil.
Check out the custom template feature (90% like SSI.php)
it can be used in websites where you need to handle a lot of pages and people contribution..
OK, I'm going to reiterate a point that I think has been forgotten.
I'm not bashing WP based on what I've seen. I USE WP CURRENTLY ON TWO SITES. I know exactly what it's capable of. Anything beyond a basic blog, it just can't handle. You cannot even have a page that's visible to signed in members only without *custom coding*, and not trivial custom coding, to boot. That alone rules it out of being a good CMS.
I shouldn't care about security
saying that if they're under a shared hosting and they use the web interface to upload & install stuff, they are at risk..
There's no best answer, only a selection of varyingly-bad answers, and right now I'm just sensing that not having an upload feature (like, I'll note, XenForo and quite probably vBulletin, though I haven't used it) is actually the lesser evil.
4986
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 12:41 PM »
Bear in mind it's about 9 years old now, it's pretty much the oldest PHP blogging platform, and it's still going, and its versatility with themes doesn't hurt it either.
(How many other blogging platforms running on PHP can you name?)
(How many other blogging platforms running on PHP can you name?)
4987
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 12:18 PM »
Yes, it's the same as SMF, basically, and it's a large contributing factor to why WP gets hacked quite often.
4988
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 10:40 AM »
Yeah, it's one of those things that would be very awesome, but the security aspect makes me incredibly wary about doing it.
Certainly it isn't required for alpha and can be shunted back to beta, but given that other systems are doing this exact thing (and they're paid, no less) with little apparent ill-will as a result, it does give me confidence that it might not be so bad after all.
It would certainly encourage people to think a bit more carefully about whether they really need a plugin or not.
Certainly it isn't required for alpha and can be shunted back to beta, but given that other systems are doing this exact thing (and they're paid, no less) with little apparent ill-will as a result, it does give me confidence that it might not be so bad after all.
It would certainly encourage people to think a bit more carefully about whether they really need a plugin or not.
4989
Features / Re: Post moderation
« on February 9th, 2012, 10:27 AM »
OK, so I took a crack at this last night and I debugged what was left this morning.
So right now I have the foundations in place - it's the UI that's missing. I created a temporary textbox in the admin panel and used that to indicate rules in the XML.
It's possible to construct rules on the following criteria: (and to have separate criteria for new posts vs new topics)
* in a given board or boards, or outside of given board or boards (e.g. able to say 'inside boards 1, 2 or 3' or 'all boards except board 4')
* user is or is not given id (e.g. do something if it is user id 1, do something if it is not user id 1)
* postcount is above/below a certain level (e.g. do something if count < 10, or count >= 20)
* warning level is above/below a certain level (e.g. do something if warning <= 10 or > 60)
* subject or body contain a given arbitrary regex (e.g. you can do something if a post contains profanity)
* user is in, or not in, certain groups (e.g. user is part of group 1 or not part of group 1)
* user has a given permission, or doesn't (e.g. do something if user has ability to lock any topic)
That last one is quite important as quite a few different tasks as available to be carried out.
* prevent the post being made at all (throws it back to the post editing screen with a warning about containing words that are not permitted; the warning itself is not actually specific to the content refused)
* place the post in moderation
* lock/unlock the topic
* pin/unpin the topic
To put it into context, you can specify - for example, that if the post contains ^/lock and the user has permission to lock any topic, that it will be locked automatically.
Rules are thus cumulative - a given rule can happily test for multiple criteria before acting. You can - as I tested this morning, for example - create a rule whereby if a non-admin posts the word 'fuck', the post is disallowed entirely - but the admin is free to post this happily.
IOW, all of the underlying behaviour set out in this topic is implemented and - thus far - seems to be working, though there's no UI (which has other stuff that needs to be managed where replacing the older setup)
Known caveats/issues:
* There's no logic for handling own vs any permissions at this point, and I'm not really sure it needs it - replying to own vs any is already a physical permission that's handled normally, it's mostly for the lock topic stuff and I'd argue if you're locking a topic based on something the user can do or not do, you probably shouldn't be giving it to everyone anyway.
* Can't yet handle based on number of replies (e.g. when 200 replies are in a topic, lock it)
* It's not possible to return a non-generic error on going back to the user.
* It's also not possible to do something like warn a user (but I'd argue that unless the post is going directly to moderation and nowhere else, the user probably shouldn't receive a warning)
* The outcome of rules action on a post is not logged at this point in time unless it's an existing moderation action (if you use the lock-topic option for example, the act of locking a topic will become logged but only because the existing code is still used)
It's a WIP from about 4 hours work :)
The one thing that bugs me is what to do about attachments. Right now the system just hijacks the original moderation, it doesn't deal with any of the permissions and it very definitely doesn't care about attachments (they would fall into the original code which is, make them unapproved unless they have permission to post attachments without worrying about approval) - but I'm honestly wondering whether it's actually an issue or not.
Do we actually care about attachments requiring approval? I'd argue that it should be tied to the post's approval status rather than the attachment itself being approved.
So right now I have the foundations in place - it's the UI that's missing. I created a temporary textbox in the admin panel and used that to indicate rules in the XML.
It's possible to construct rules on the following criteria: (and to have separate criteria for new posts vs new topics)
* in a given board or boards, or outside of given board or boards (e.g. able to say 'inside boards 1, 2 or 3' or 'all boards except board 4')
* user is or is not given id (e.g. do something if it is user id 1, do something if it is not user id 1)
* postcount is above/below a certain level (e.g. do something if count < 10, or count >= 20)
* warning level is above/below a certain level (e.g. do something if warning <= 10 or > 60)
* subject or body contain a given arbitrary regex (e.g. you can do something if a post contains profanity)
* user is in, or not in, certain groups (e.g. user is part of group 1 or not part of group 1)
* user has a given permission, or doesn't (e.g. do something if user has ability to lock any topic)
That last one is quite important as quite a few different tasks as available to be carried out.
* prevent the post being made at all (throws it back to the post editing screen with a warning about containing words that are not permitted; the warning itself is not actually specific to the content refused)
* place the post in moderation
* lock/unlock the topic
* pin/unpin the topic
To put it into context, you can specify - for example, that if the post contains ^/lock and the user has permission to lock any topic, that it will be locked automatically.
Rules are thus cumulative - a given rule can happily test for multiple criteria before acting. You can - as I tested this morning, for example - create a rule whereby if a non-admin posts the word 'fuck', the post is disallowed entirely - but the admin is free to post this happily.
IOW, all of the underlying behaviour set out in this topic is implemented and - thus far - seems to be working, though there's no UI (which has other stuff that needs to be managed where replacing the older setup)
Known caveats/issues:
* There's no logic for handling own vs any permissions at this point, and I'm not really sure it needs it - replying to own vs any is already a physical permission that's handled normally, it's mostly for the lock topic stuff and I'd argue if you're locking a topic based on something the user can do or not do, you probably shouldn't be giving it to everyone anyway.
* Can't yet handle based on number of replies (e.g. when 200 replies are in a topic, lock it)
* It's not possible to return a non-generic error on going back to the user.
* It's also not possible to do something like warn a user (but I'd argue that unless the post is going directly to moderation and nowhere else, the user probably shouldn't receive a warning)
* The outcome of rules action on a post is not logged at this point in time unless it's an existing moderation action (if you use the lock-topic option for example, the act of locking a topic will become logged but only because the existing code is still used)
It's a WIP from about 4 hours work :)
The one thing that bugs me is what to do about attachments. Right now the system just hijacks the original moderation, it doesn't deal with any of the permissions and it very definitely doesn't care about attachments (they would fall into the original code which is, make them unapproved unless they have permission to post attachments without worrying about approval) - but I'm honestly wondering whether it's actually an issue or not.
Do we actually care about attachments requiring approval? I'd argue that it should be tied to the post's approval status rather than the attachment itself being approved.
4990
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 10:08 AM »
Making it writable from PHP means exposing it to being writable by the web server. Convenient, sure, but on shared hosting, you have to make it writable to all users since on most shared hosts I've seen, the web server user is not the same as the owner of the files and very often isn't in the same group - meaning that your files have to be world writable by definition.
This is why systems get hacked: folks change the permissions and trigger the system to abuse it. Now, if you're not modifying core files, you limit the damage that can be done - but still all the plugin files are within the cross-hairs, and anything on that server that happens to get compromised, can compromise any and all plugins. Even attachments aren't really that safe - but they're safe in that they can't directly be executed by the server (or at least, on anything remotely sane, shouldn't be able to be executed), though attachments I accept have to remain world writable by definition.
On the other hand, if users have to upload plugins, they get them uploaded via FTP and invariably that just works as expected. The plugin gets uploaded, it's not writable by the web server so it's protected from being infected by any other compromised site on the server.
Yes, it's not as convenient as having something that does it all magically, but I'd argue it's a lot safer and doesn't require what amounts to a workaround.
What's more important: being secure or being convenient? You know as well as I do that users don't actually care about being secure, but they love convenience, and we have to make a call on what we think as more important, because we have to care when the user doesn't.
This is why systems get hacked: folks change the permissions and trigger the system to abuse it. Now, if you're not modifying core files, you limit the damage that can be done - but still all the plugin files are within the cross-hairs, and anything on that server that happens to get compromised, can compromise any and all plugins. Even attachments aren't really that safe - but they're safe in that they can't directly be executed by the server (or at least, on anything remotely sane, shouldn't be able to be executed), though attachments I accept have to remain world writable by definition.
On the other hand, if users have to upload plugins, they get them uploaded via FTP and invariably that just works as expected. The plugin gets uploaded, it's not writable by the web server so it's protected from being infected by any other compromised site on the server.
Yes, it's not as convenient as having something that does it all magically, but I'd argue it's a lot safer and doesn't require what amounts to a workaround.
What's more important: being secure or being convenient? You know as well as I do that users don't actually care about being secure, but they love convenience, and we have to make a call on what we think as more important, because we have to care when the user doesn't.
4991
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 08:59 AM »
Well, it still has some useful stuff like dealing with unpacking mods and so on - but the more I think about it the more I am kind of leaning towards what XenForo does - and not having any kind of unpacking on the server. It certainly solves permissions headaches but isn't so friendly.
4992
Plugins / Re: Plugin Manager: Mechanics
« on February 9th, 2012, 02:46 AM »
It needs updating to reflect the correct title too. I'll deal with it when I get chance, thanks for reminding me :)
Now updated to actually be more accurate.
Posted: February 9th, 2012, 02:30 AM
Now updated to actually be more accurate.
4994
Plugins / Re: Exposing bbcode to the plugin manager
« on February 8th, 2012, 11:42 PM »
I'm not thinking it would, generally.
Here's the thing: disabled has 3 uses, all sort of related.
Firstly, it's extracted from the master modSettings entry, and that's done on first entering parse_bbc. Now, it's used once by the print code to turn off certain codes, then it's used to check whether certain codes are active or not, and add other codes (e.g. the mutant list codes) and lastly it's actually used to ignore tags when parsing.
The key point is that it isn't cached, so that the master list of tags is always consistent, even if you switch between normal and print-page within the cache lifetime, you won't get mashed up tags.
Ignoring the master modSetting and rebuilding it from the main tag list should be a one-per-page affair (when the master bbcodes are loaded, after cache retrieval occurs), so the hit should not be that serious at all.
Really, though, a lot more of it is figuring out how the UI should interact so that the loading can handle everything it's supposed to and set disabled appropriately - setting 'url' to disabled takes out all variants on the url bbcode, not just any one particular style.
Here's the thing: disabled has 3 uses, all sort of related.
Firstly, it's extracted from the master modSettings entry, and that's done on first entering parse_bbc. Now, it's used once by the print code to turn off certain codes, then it's used to check whether certain codes are active or not, and add other codes (e.g. the mutant list codes) and lastly it's actually used to ignore tags when parsing.
The key point is that it isn't cached, so that the master list of tags is always consistent, even if you switch between normal and print-page within the cache lifetime, you won't get mashed up tags.
Ignoring the master modSetting and rebuilding it from the main tag list should be a one-per-page affair (when the master bbcodes are loaded, after cache retrieval occurs), so the hit should not be that serious at all.
Really, though, a lot more of it is figuring out how the UI should interact so that the loading can handle everything it's supposed to and set disabled appropriately - setting 'url' to disabled takes out all variants on the url bbcode, not just any one particular style.