Wikimedia Bugzilla is closed!

Thank you for submitting a patch.

Unfortunately, this patch has the same problems as the one on bug 15129, as I noted in comment 26:

> Especially with a high sensitivity module such as CU, I really do want to have
> a common backend for the special page and the API module. With all the code
> duplication the chances that are high that security vulnerabilities and other
> bugs that are found in the API module and fixed are not propagated to the
> special page and vice versa. Considering the sensitivity of CheckUser I do not
> think that this is acceptable.

*** This bug has been marked as a duplicate of bug 15129 ***

Hm, I don't duplicate existing CheckUser functions. Only two functions taken from main CheckUser class.

You suggest rewrite xff as boolean parameter? Or something changes?

This patch tested on trunk version of MediaWiki and don't have vulnerabilities - for validations IPs and usernames used same functions as on main CheckUser class (call them from this class is not real, but this functions marked as protected).

(In reply to comment #2)
> Hm, I don't duplicate existing CheckUser functions. Only two functions taken
> from main CheckUser class.
> 
With code duplication I mean copy-pasting of functions. My point is that by doing all the backend work in different places for the UI and API, it is easy for those code paths to diverge, which is an increased in maintenance burden, and is a potential risk for future security problems. 
There are numerous essays on the web that do a better job in explaining why copy-pasting code is bad than me. See for example [1], under the heading "Why is code duplication bad?"

[1] http://www.solidsourceit.com/blog/?p=4

Ok, thanks for explanation.

I rewrite this functions and xff requests syntax during the one-two days. However, rewrite addLogEntry function is difficult but performed by this function actions is absolute identical for specialpage and API.

You can see ways to solve this problem? Maybe, need declare addLogEntry function in CheckUser class as public (I don't see any vulnerabilities with this function) or some other way?

Yeah a whole lot of these protected functions in SpecialCheckUser should be public static, or even moved to a separate class.

Ideally, you would be able to do something like

$users = CheckUser::doIPUsersRequest()
CheckUser::addLogEntry()

This is quite a lot of work, with all the $wgOut calls intermixed with the database querying.

Created attachment 9243 [details]
new version of patch

I rewrite code of API module, remove copy-pasted code and change used classes of CheckUser to public static and their calls.

Looks good. Can you make the diff in unified diff format (specify -u on the command line I believe)

Created attachment 9245 [details]
patch

Done.

Thank you for the patch, cryptocoryne!  Mark and I will try to get someone to review it sooner rather than later.  :-)

Very well done, cryptocoryne. That patch was near flawless and was committed in r100165.  Just a few notes on stuff I changed so you can learn:

In ApiQueryCheckUser you I had this line:

  +        $reason = 'API: ' . $params['reason'];

Which I changed to:

  +        $reason = wfMsgForContent( 'checkuser-reason-api' ) . ' ' . $params['reason'];

This allows the 'API:' part to be translated.

*** Bug 15129 has been marked as a duplicate of this bug. ***

Well, it had calls like $this->addWhere( "cuc_user_text = '$target'" ); which allowed SQL injection...