1 Arif Jun 12, 2006 10:18
2 mallika May 16, 2006 15:25
in response to: XML-RPC vulnerability
3 Terry Remsik Feb 15, 2006 20:37
in response to: Transaction support (non critical)
4 erik Jan 19, 2006 00:47
in response to: Login / Session
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!
5 Ian Jan 17, 2006 17:59
in response to: UTF-8 and Japanese support
6 Filthio Dec 31, 2005 18:35
in response to: Editing permissions
See debate at http://forums.b2evolution.net/viewtopic.php?t=5291&highlight=url
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.
7 topanga Nov 28, 2005 14:55
in response to: Editing permissions
Go ahaed.
I’m witing for this to happen…
8 Anthon D. Coppedge Nov 11, 2005 23:55
in response to: # of posts and recent comments to be displayed
9 fplanque Nov 02, 2005 11:01
in response to: Save skin for each blog
okay for the ( ) enclosing.
Not okay for the serialize. The cookie MUST remain human readable (because of the paranoïds out there).
10 blueyed Oct 31, 2005 23:35
in response to: Save skin for each blog
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:
skins=(#2:custom;#3:guadeloupe;#5:originalB2)
We should also consider (un)serialize().
Of course, this must be safe against injections in either case!
11 edbennett Oct 04, 2005 20:04
in response to: Editing permissions
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.
12 edbennett Oct 04, 2005 19:54
in response to: update blacklist before report a spammer
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.
13 kwa Sep 28, 2005 14:44
in response to: update blacklist before report a spammer
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…
14 fplanque Sep 05, 2005 19:20
in response to: update blacklist before report a spammer
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 ;)
15 fplanque Aug 31, 2005 19:45
in response to: XML-RPC vulnerability
The patch for version 1.2 is available here on SourceForge.
16 Paul Aug 31, 2005 18:39
in response to: XML-RPC vulnerability
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.
17 Kinari Aug 30, 2005 06:11
in response to: UTF-8 and Japanese support
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?
18 Chris Aug 23, 2005 20:30
in response to: Editing Toolbar
This functionality is the feature that is keeping me from moving to b2evolution. Wordpress 1.6 has added wysiwyg via the TinyMCE
Hello! I am new in using b2evolution. I am seeking for an importer tool from WordPress to b2evolution. Have any body worked on it?