Auth systems/OAuth/IRC log 2013-04-18

Apr 19 11:06:16 	Can we cherry pick in Aaron's change on top of anomie's work? Apr 19 11:06:38 	I don't see why not Apr 19 11:07:14 	Cool. Do one of you have time to do that tomorrow? Apr 19 11:08:19 	I should be able to find time Apr 19 11:08:32 	Cool, thanks! Apr 19 11:09:20 	Alright, I also added some testing scenarios at https://www.mediawiki.org/wiki/Auth_systems/SUL2/Testing Apr 19 11:09:27 	(very basic) Apr 19 11:10:03 	If there are any particular cases we should make sure work in all browsers, please add them Apr 19 11:10:19 	Is it possible anymore to create a local-only account? Apr 19 11:10:51 	You can't create them, but you can create an account that is global, and then detach it Apr 19 11:10:58 	right Apr 19 11:12:10 	*hopefully* after the "SUL finalization" we won't even allow that... but I'm guessing there is always going to be an edge case where someone could end up with a detached account. So I wanted to make sure nothing unexpected happens. Apr 19 11:12:49 	Hopefully. :-) Apr 19 11:13:14 	anomie / Aaron|home, anything you guys are waiting on or need on the CentralAuth rework? Otherwise I wanted to move on to some oauth stuff.. Apr 19 11:13:51 	Just review Apr 19 11:14:11 	nothing here Apr 19 11:14:42 	I'll try and take a look at both soon, again. Apr 19 11:15:24 	Alright, so while as we're finishing out the CentralAuth stuff, we do need to start coding the OAuth side too Apr 19 11:15:30 	I made a few updates to https://www.mediawiki.org/wiki/Auth_systems/OAuth Apr 19 11:15:44 	(and drew a picture, since I'm a visual person) Apr 19 11:16:13 	Can we talk about the permissions open question? Apr 19 11:17:24 	http://www.mediawiki.org/wiki/Auth_systems/OAuth#granularity-question Apr 19 11:17:46 	Brad added some thoughts on modules vs. rights Apr 19 11:18:37 	I was wondering if we wanted to add a separate permission-ish something for anything making changes to MediaWiki namespace Apr 19 11:19:03 	But did anyone else have thoughts on what the right approach might be? Apr 19 11:19:21 	I think the way to go is to just add a method to ApiBase for the API module to just say what rights it needs, rather than trying to fit things to user rights or API module names. Then we can divide up namespaces however makes sense for each module. Apr 19 11:20:33 	So that would be the third bullet? Apr 19 11:20:37 	Yeah. Apr 19 11:20:38 	The default can be the module name, so we won't have to update every API-using extension right away. Apr 19 11:21:49 	So it would be module-ish, but modules could override the default and require more specific (or the name of another module) for specific actions, right? Apr 19 11:22:07 	And the user rights of the user would still apply Apr 19 11:22:17 	that might be reasonable Apr 19 11:22:32 	Yes. So most of the public query modules could just say "query", while something like ApiEditPage could list "edit", "editinterface", "editmycssjs", etc Apr 19 11:22:46 	Yes, this wouldn't affect the existing user rights checks at all. Apr 19 11:22:54 	This would be another check on top of them. Apr 19 11:23:05 	presumably the method would need access to the request parameters if it is going to conditionally return editinterface etc. Apr 19 11:25:19 	Which is easy enough, just call ->extractRequestParams. Or maybe it could check as needed inside execute, too. Apr 19 11:29:00 	So anomie, were you thinking ApiBase would call into the module with a list of oauth permission, and the the module would do the logic to decide if the call was appropriate for the permissions, right? Apr 19 11:29:12 	(if I understand what you're thinking) Apr 19 11:31:05 	Actually, I hadn't thought about it. I had been sort of thinking the module would say what permissions it needs, but your way seems more amenable to giving partial results with warnings about unavailable bits rather than hard errors. Apr 19 11:33:15 	Well, doing it like that would mean that some api modules would have to basically become oauth aware, which seems a little wrong. But I'm not sure a better way to do it. Apr 19 11:34:27 	s/like that/my way above/ Apr 19 11:34:31 	No matter what they'll have to be auth aware, unless they want the basic "module name" deal. But I think we can do it generically enough that it's not oauth-specific. Apr 19 11:35:46 	e.g. ApiEditPage would know it needs "edit" or "editinterface" or whatever, but it wouldn't have to know how it was determined that the user has those grants. Apr 19 11:36:01 	So basically make them "authorization aware", and let the module decide based on the user's authn's Apr 19 11:37:12 	Hmm... that would actually solve some of our issues with the api returning deleted data to unauthorized users, if we did it right... Apr 19 11:37:30 	We have issues with that? Apr 19 11:38:14 	We definitely have Apr 19 11:38:58 	I should probably look at those at some point. Apr 19 11:40:24 	A little brainstorming: ApiMain calls $wgAuth->checkGrantsForApiModule( $module ), which might do nothing (if the auth module grants everything) or might look up what grants are granted and call $module->checkApiGrants( $grants ). Return a Status object, I suppose. Apr 19 11:42:22 	Off the top of my head, that sounds reasonable Apr 19 11:42:39 	Tim / Aaron, any thoughts on it ^? Apr 19 11:44:58 	maybe it could be implemented analogously to isReadMode/isWriteMode Apr 19 11:45:19 	i.e. in ApiMain::executeAction or ApiMain::checkExecutePermissions Apr 19 11:45:52 	Yeah, checkExecutePermissions is a good place to have it make the call. Apr 19 11:46:10 	the rest is all fine, I think Apr 19 11:47:02 	Cool. Thanks. Alright, I'll keep writing this up Apr 19 11:47:37 	I think we're almost to the point of looking at db schema and basic class design Apr 19 11:48:04 	I'll try and take a stab at that tomorrow, and maybe we can talk more on Monday Apr 19 11:48:18 	Than actually start some code next week Apr 19 11:49:32 	Alright, that's all I have Apr 19 12:06:47 *	Aaron|home backscrolls Apr 19 12:06:55 	csteipp: yes, checkExecutePermissions seems sanish