#2 Sep 03, 2005 19:42
Has this happened to you?
You make a long post, hit "save" and then get one of the following three messages:
Found invalid URL: Invalid URL
Found invalid URL: URI scheme not allowed
Found invalid URL: URL not allowed
It can be difficult to figure out WHICH HREF link is causing the problem (let alone WHY there's a problem).
You COULD turn off the html-checker, which will simply allow anything to fly .... OR ... by modifying the b2evocore/_functions.php file, you can obtain more useful feedback.
Edit the following: (around line 1047) look for " * Check the validity of a given URL"
In the section immediately below
Change: return T_('Invalid URL'); to: return T_('Invalid URL - <strong>['.$url.']</strong>');
Change: return T_('URI scheme not allowed'); to: return T_('URI scheme not allowed - <strong>['.$scheme.']</strong>');
Change: if( $debug ) return 'Url refused. Debug info: blacklisted word: ['.$block.']'; to: return T_('<strong>['.$url.']</strong> - not allowed because of blacklisted word - <strong>['.$block.']</strong>');
This feedback will make it much easier to track down WHAT is causing the problem (and often, it'll give you a good idea of WHY it's causing a problem too).
Hope this helps :D
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');
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?
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.
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.
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.
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 ;)
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.
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!