Great. Thanks!

Question for ya. In your lastly situation it looks like you want to replace the "if debug" conditional with a plain old return thingie. I'm looking at v0.9.1 and thinking I should replace

		if( $debug ) return 'Url refused. Debug info: blacklisted word: ['.$block.']';
		return T_('URL not allowed');

with

		if( $debug ) return 'Url refused. Debug info: blacklisted word: ['.$block.']';
		return T_('<strong>['.$url.']</strong> - not allowed because of blacklisted word - <strong>['.$block.']</strong>');

Am I on track here?

Ed,

Sorry for the lately reply. :oops:

You prolly figured it out, but no, I replaced the whole "if ($debug)" statement with the return. Reason ... I wanted feedback regardless of the $debug setting.

-stk

Cool. I was thinking what do I need the debug thing for since I debug by looking at the error and scratching my head a bit. Anyway I opted to do it as I posted, and am now reminded I might be able to save my server a nanosecond or two by dumping all those "if debug" thingies. At least I think I did the hack... I guess I should try to link to something banned to see if I get the message. Maybe log out and comment too.

Thanks stk, I've added it to CVS HEAD ("Phoenix").

Excellent. I think folks will like the added information.

Cheers,

-stk :D

Actually, François rolled it back, because it would allow cross-site-scripting.

This is disappointing, but I thank you for taking the time to follow up (my one contribution ... hacked out 8| ;) )

I wouldn't know cross-site-scripting from cross-dressed-man, but I do know that security is paramount.

Hopefully, more meaningful feedback can be allowed, without running a security (or safe-sex) risk.

Cheers,

-stk :D

I was delighted to find that hack - thanks stk, fine work sir. I've implemented it, and it's damned useful. I've also put some friendlier messages on it for visitors to see, including the words 'Sorry', for example.

However I note François' concern about security and like everyone should, I respect that sort of thing. Now I haven't the faintest what the risk is here, can anyone quantify?

At the end of it, I agree with the many wiser heads that mine who have suggested that antispam should be togglable for admins. It just seems like a feature waiting to be implemented... or possibly, to be deimplemented ;)

http://www.naturenet.net/blogs

I'm not hip on all the security issues, as well (which is why I boldly changed the code here to provide more feedback).

One issue that I CAN think of, is you don't want spammers to know "what's" in the blacklist (and reporting back a failure for comments on a blacklisted URL would do that ... as I've got the hack posted above).

A better implementation would be to provide this feedback ONLY for priviledged bloggers (and not for commentors). Which can be done and perhaps I'll mod the code to allow for it.

If it were up to me (and it's not) I'd prefer to see a separation between POST checking and COMMENT checking. In a single author install, I believe it's important that the blogger be allowed to post what he/she wants. If they continually trip over the html-checker and url_validation, they'll just lose faith in these things and turn them off (which, because it also controls comments ... could spell disaster for blog security). Likewise, while keeping feedback from commentor is important, from a security point of view, MORE feedback is desirable for posters. (Hence this hack and the positive reaction to it).

Personally, I'd like to see a comment preview, as well ... allowing commentors to see if they've committed any XHTML sins, posted an invalid/blacklisted URL or just to see how their formatting looks. As it stands now, the default install ungraciously spits out an Invalid URL error, plus the "option" to 'go back to comment editing' (which goes back to a blank comment form in IE) - YUCK. :-/

The ergonometrics here are not ideal and I think it could benefit from more attention.

-Hope this helps.

-stk :D

Separation of POST and COMMENT is an excellent idea. The distinction would work with whatever user permissions were already set up, and it should simply be possible to set the security level, separately, for both POST and COMMENT. Or maybe, if anyone really is enthusiastic enough to have ten different levels of users, they could set them via that, with each user level having possible access to post and comment.

As for a spammer getting a copy of the blacklist - a good point, but, if you were a spammer, and wanted to see the b2evo blacklist, wouldn't you just get it the same way we all do? I suspect the real security risk is something more subtle than that, but I guess you and I will just have to scratch our heads about that for a while longer!

Cheers m8