Last modified: 2014-08-27 19:16:53 UTC
11:54 < anomie> legoktm, ebernhardson: ... This would be a lot easier if action=flow could just always use a token, instead of using one sometimes and sometimes not. 11:54 < Reedy> read modules are usually action=query submodules 11:56 < legoktm> making it an action=query module would be a nice thing, but the read and write modules shared a lot of common code and I couldn't really think of a good way to make that work without just having them be one large submodule 11:57 < legoktm> also, when I first started writing it, action=flow was just write stuff, and then we added some read modules to it 12:03 < anomie> legoktm, ebernhardson: Hmm. So it probably doesn't make a whole lot of sense to have the flow read actions being a query submodule, since action=query&meta=flow&flowsubmodule=... is kind of silly when we could do action=flowquery. If you want to keep them all in action=flow, it would basically mean reimplementing the core token handling because core doesn't have a way to conditionally have action=flow take a token. 12:07 < anomie> ebernhardson: With a little trickery you can have the ApiFlow implement both action=flow and action=flowquery: just check $action in the constructor to set the return value of needsToken() (false or 'csrf') and use the appropriate list of submodules. Then everything about needsToken can be removed from ApiFlowBase and all the token checking can be removed from ApiFlow::execute().
Revert https://gerrit.wikimedia.org/r/#/c/156600/ when closing this bug