https://bugzilla.wikimedia.org/show_bug.cgi?id=32819
Bawolff <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Bawolff <[email protected]> 2011-12-15 06:56:57 UTC --- Thought I'd look over this extension and give some thoughts: Line 28 of InteractiveBlockedMessage.php: $wgAutoloadClasses['InteractiveBlockMessage'] = "$dir/InteractiveBlockMessage.php"; I'm not sure what that's about (It won't hurt anything, but there is no such class, so it probably shouldn't be there) *LanguageGetMagic hook usage - That's probably ok, but if you use a .magic.i18n.php file, the magic word name can be translated at translatewiki (I think anyways) *MagicWord id being all capitalized - Doesn't really matter, but the magic word id (not the actual magic word, just its internal id) are all lowercase for all the magic words in core *$user->isBlocked() call - should perhaps pass a true to explicitly ask the result to come from slave (doesn't really matter though, since slave is default, but good to be explicit) *Doesn't work on anon user pages (not sure if intentional or not. if it's wanted, all that needs to be done is pass false as second argument to user::newFromName) if it did work for anons, there might be security implications in revealing auto-blocks (As mentioned on the en wp page, although given the number of autoblocks in place at one time, it'd be difficult to glean much from this, but still not a good thing) *If the user causes their own user page to be rendered, the magic word will report true if the user is blocked via auto-blocks, proxy auto-blocker, or DNSBL block (although I don't think the last two are used by wikimedia). This is inconsistent (Compared to other people rendering the page), and probably a bad thing (Although not horrible). Perhaps better to use Block::newFromTarget directly, in which case it would only look at explicit blocks (and could also be used on anon user pages without leaking auto-blocks). *We should perhaps add a hook to SpecialUnblock::processUnblock so that this extension could explicitly purge user pages on an explicit unblock. -- Cheers ------- btw, does this extension still need review by the senior dev cabal? (I know there is a mailing list thread about that) if so, it should have the keyword "need-review" and be blocking bug 31235. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
