Bryan.TongMinh wrote:

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 ***

cryptocoryne76 wrote:

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).

Bryan.TongMinh wrote:

(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

cryptocoryne76 wrote:

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?

Bryan.TongMinh wrote:

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.

cryptocoryne76 wrote:

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.

attachment checkuser.patch ignored as obsolete

Bryan.TongMinh wrote:

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

cryptocoryne76 wrote:

patch

Done.

Attached:

sumanah wrote:

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

john wrote:

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.

john wrote:

*** 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...