Last modified: 2012-11-03 09:27:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 21991 - Move common user query parameter validation, edit token requiringness/checking to ApiBase/Similar
Move common user query parameter validation, edit token requiringness/checkin...
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 21966
  Show dependency treegraph
 
Reported: 2010-01-01 23:41 UTC by Sam Reed (reedy)
Modified: 2012-11-03 09:27 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sam Reed (reedy) 2010-01-01 23:41:20 UTC
Seemingly (at least!) 3 different ways of validating/whinging at the user for the user parameters.

Commonise and reuse.

They can still apply more restrictive validation (!anon etc) themselves

As per IRC convo beneath:

[23:29:26] <|reedy|> http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcuser=User:Reedy
[23:29:28] <|reedy|> http://en.wikipedia.org/w/api.php?action=query&list=logevents&leuser=User:Reedy
[23:29:51] <|reedy|> RoanKattouw: seemingly 3 different (at least) sets of behaviour
[23:30:24] <|reedy|> http://en.wikipedia.org/w/api.php?action=query&format=xml&list=usercontribs&ucuser=User:Reedy
[23:30:30] <RoanKattouw> Yeah I assumed that'd be it
[23:30:32] <RoanKattouw> Interesting
[23:30:36] <|reedy|> heh
[23:30:44] <|reedy|> I was looking at bug 21966 to see "how its done elsewhere"
[23:30:51] <RoanKattouw> uc reads your mind, le throws an error, rc literally looks for User:User:Reedy
[23:30:57] <|reedy|> Yup
[23:31:00] <|reedy|> Tbh
[23:31:17] <|reedy|> Shouldn't the validation for this bit be done in a parent class and kept the same for all?
[23:31:59] <RoanKattouw> |reedy|: Yes, it should happen in ApiBase
[23:32:10] <RoanKattouw> Well.... not necessarily
[23:32:24] <|reedy|> Well, somewhere common.. As they should all experience the same validation
[23:32:25] <RoanKattouw> For instance, usercontribs allows ucuser=1.2.3.4 , but logevents doesn't
[23:32:40] <RoanKattouw> Because anonymous users cannot have log entries
[23:32:42] <|reedy|> I mean, at least, the method, can still do its own, and call the common
[23:32:43] <|reedy|> Sure
[23:32:49] <RoanKattouw> But anons can have contribs and RC
[23:33:21] <RoanKattouw> |reedy|: Yeah, so the basic ApiBase validation should just be the uc&rc stuff, and then le can add it's no-anons strictness itself
[23:33:29] <|reedy|> Yup
[23:38:13] <RoanKattouw> |reedy|: Yeah well since I'm not a volunteer anymore (it's 2010 now, I get paid again, yay) I probably won't be getting to it any time soon
[23:33:37] <RoanKattouw> Although I'm not sure anyone's actually tested with 6, only aware of 5.3
[23:34:19] <RoanKattouw> Of course usercontribs and RC still validate differently, that should be made consistent
[23:34:24] <|reedy|> RoanKattouw: i suppose thats possibly the way to do it... Shall i log it as an enhancement and put it as blocking 21966?
[23:34:37] <|reedy|> cause "fixing" that will fix 21966 in one way or another
[23:34:43] <RoanKattouw> That's true
[23:35:03] <RoanKattouw> Yeah go ahead and do that, unless you feel like fixing this in the short term
[23:35:29] <|reedy|> RoanKattouw: i may get to it, not too difficult, just needs some time i suppose :)
Comment 1 Sam Reed (reedy) 2010-01-03 13:52:59 UTC
Oh Roan, I should've really asked.. Which way do we want to move to?
Comment 2 Roan Kattouw 2010-01-03 16:40:16 UTC
(In reply to comment #1)
> Oh Roan, I should've really asked.. Which way do we want to move to?
> 

Ideally, the 'user' parameter type would trigger validation code in ApiBase that is relatively relaxed and validates rc-style (allow IPs, throw error on invalid stuff, don't mess with namespace prefixes so &rcuser=Talk:Foo means User:Talk:Foo and &rcuser=User:Foo means User:User:Foo ; the latter is presumably invalid). Logevents can then enforce the user-must-exist criterion by just checking $user->isLoggedIn() and throwing an error if that returns false.

Disclaimer: I don't know offhand which validation function does this. I think it's User::getCanonicalName() or a related function; see http://svn.wikimedia.org/doc/classUser.html
Comment 3 Sam Reed (reedy) 2010-02-14 15:34:12 UTC
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62402#c5774

Token requiring/checking

Retitling to cater for this
Comment 4 Sam Reed (reedy) 2010-02-14 22:22:10 UTC
r62482 does the token requireness check :)
Comment 5 Sam Reed (reedy) 2010-02-14 22:37:55 UTC
It seems there is only one hashed token...

		if ( !$wgUser->matchEditToken( $params['token'], $user->getName() ) )

in ApiUserrights.php

Simplest way to deal with this, would seem to be, in that module, don't have the checks done in ApiMain for this.

Or we have another method property like

public function checkToken() {
return true;
}

And default this to false for this module, and it can hash check it's own way if it wants...

Either or seems to be sensible
Comment 6 Sam Reed (reedy) 2010-02-14 22:39:00 UTC
*It seems there is only one salted token.
Comment 7 Roan Kattouw 2010-02-15 14:17:32 UTC
(In reply to comment #5)
> It seems there is only one hashed token...
> 
>         if ( !$wgUser->matchEditToken( $params['token'], $user->getName() ) )
> 
> in ApiUserrights.php
> 
There's another one in ApiRollback.php

> Simplest way to deal with this, would seem to be, in that module, don't have
> the checks done in ApiMain for this.
> 
> Or we have another method property like
> 
> public function checkToken() {
> return true;
> }
> 
> And default this to false for this module, and it can hash check it's own way
> if it wants...
> 
> Either or seems to be sensible
I'd recommend introducing a function that returns the salt (usually the empty string, and false if there's no token to be checked), see also CR r62482.
Comment 8 Sam Reed (reedy) 2010-02-15 23:54:15 UTC
r62557 does the validation of the token where possible
Comment 9 Sam Reed (reedy) 2010-02-17 00:14:46 UTC
Token requiringness/checking is now done.

Including in the extensions in the SVN
Comment 10 Sam Reed (reedy) 2010-02-17 09:45:33 UTC
Minor title tweak - rc and uc weren't what we were actually looking at changing, we were just looking at the *user parameter!
Comment 11 Krinkle 2011-12-06 22:02:26 UTC
Just like validation of string/integer/timestamp etc. is centralized in ApiBase.php, perhaps a new PARAM_TYPE could be added for 'username' ?
Comment 12 Sam Reed (reedy) 2011-12-06 22:30:57 UTC
(In reply to comment #11)
> Just like validation of string/integer/timestamp etc. is centralized in
> ApiBase.php, perhaps a new PARAM_TYPE could be added for 'username' ?

That would work.

The question is how far do we go validating it - Just as far as "Would MW let you have this username?" and if so, carrying on? And/or it will make a valid User object (though, shouldn't these 2 things be essentially the same?)?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links