I would like to do my part in making this one more popular.
All listed items are good and part of good security practice.
I was hacking around in the “Amsterdam” code and went pale when I saw how it was handled there :-(.
my vote for this one!
I’d be very keen to see some further implementation of the user levels - could be useful. But what about separating the editing of COMMENTS from POSTS? The current antispam restrictions are very user unfriendly for innocent visitors trying to comment. It would be nice to have a user status which over-rides antispam (for admins), as well as a default entry-level permission for unverified users.
I’m witing for this to happen…
okay for the ( ) enclosing.
Not okay for the serialize. The cookie MUST remain human readable (because of the paranoïds out there).
Because other variables can get stored there later, I’d say to rather use a more strict format to allow parsing of it,
like at least:
We should also consider (un)serialize().
Of course, this must be safe against injections in either case!
I did a hack along these lines but did NOT include a user interface. I really like the idea of “> or >=” your current level (or group). To me it’s both a feature (when you want collaboration) and a flaw (when your bloggers are entirely independent authors), and therefore should be something the admin can define on a blog-by-blog basis.
The problem with saying “your local copy is more than N days old” is that we are obligated to publish a new spammer within that time frame. Once I recall a case where central wasn’t updated for quite some time, so, if a time limit based on last update was implemented it would be possible for no one to report. Another issue is that updating the blacklist won’t purge the hitlog table of all hits that would have matched. Therefore the person who has an up-to-date list will still have spam in their logs, and should still report those ‘referers’ they deem spam.
I suggest altering the message(s) the reporter sees each time they report. If they do not have the latest update time stamp (or something reasonably close…) they get “thanks for reporting/adding - and UPDATE YOUR LIST!!!". I suppose it would take including the settings value as part of the update, which won’t help those on an older version, but it’s a potential step for the future.
Another idea along these lines is probably more complex than this topic allows for, but I’ll throw it out anyway. If a reported term is not explicity in the blacklist but would have been blocked by a published keyword the user should get a prompt telling them it’s already covered by “nnnnn” but thanks for adding to the report for that specific term. This way the user can see that blahblah-foo-bar.spammer.tld is already banned by -foo-, and *maybe* figure out there’s more layers to this onion than meets the eye.
Back on track: Now that I’m on the inside I embrace topanga’s concern with the difficulty of dealing with new reports that would have been banned by an up-to-date keyword list. Clearly, from a central list management perspective, something needs to be done to educate the users and deal with new domains that are already covered.
Bottom line: whatever you do, please think about the new user who doesn’t know all the ins and outs and is trying to take part in the Great Battle. Anything that stops them from reporting might make them decide to not play at all, but something that informs them will probably make them a better player.
I don’t agree with that request. I emptied my 3,000 keyword blacklist because it was too long and a few tens of spammers were spamming my blogs. Test long blacklists is CPU time consuming. My host complained about my CPU usage…
However, I still reporting new spammers and even if I update my antispam blacklist on a regular basis, I remove all the new keywords one by one. Updating, then removing all the new keywords would do the same as reporting new spamming keywords without updating the antispam blacklist…
We could do that based on the last updated date.
How much should we tolerate? 1 week?
If we make it too long, people will still report irrelevant spam.
If we make it too short, they won’t be able to report spam if we don’t update the list on our end.
A better way would be to has a date with “last checked” and force that to less than an hour or sth like that, but it’s a little more work to implement ;)
The patch for version 1.2 is available here on SourceForge.
It would seem that a new vulnerability with the xmlrpc code has been discovered since the most recent b2evo patch (see http://phpxmlrpc.sourceforge.net/)
The xmlrpc code should be updated to version 1.2 asap (would seem to be quite vulnerable until it is). The new version of xmlrpc removes all use of the eval() function which should prevent future vulnerabilities of this type.
I have been testing this in Japanese and haven’t found too many problems. One problem was that some templates have hardcoded text in them and so the translations don’t come through.
What other issues are there?
This functionality is the feature that is keeping me from moving to b2evolution. Wordpress 1.6 has added wysiwyg via the TinyMCE