Since it's hard to know the pageid (and thus the array item from pages), this can be used as a work-around with &indexpageids

$.getJSON(
wgScriptPath + '/api.php?',
{

		format: 'json',
		action: 'query',
		titles: 'Main Page',
		prop: 'info',
		indexpageids: '',
		intoken: 'edit'

},
function( data ) {

		if ( data.query.pages && data.query.pageids ) {
			pageid = data.query.pageids[0];
			token = data.query.pages[pageid].edittoken;
			alert( token );
		} else {
			alert( 'Fail!' );
		}

}
)

Yeah, looks like the JSON issue was fixed with Bug 9121 (although not documented anywhere). This is the wordaround mentioned by Krinkle above. I still think it would be much more elegant in the long term to have a simple dedicated command for retrieving the token by itself, rather than having to specify a page and dig it out from the data tree.

Actually I was wrong. Indexpageid is listed in the auto-generated documentation. I've added it to the on-wiki documentation now as well.

This in theory, should be trivial enough to fix. Not quite sure why it was coded as such originally, might be worth checking out, even if it's "we didn't expect people to just want X token".

Will poke at later somepoint

Since tokens are session specific rather than page specific, it doesn't make
sense that you have to tie your request for a token to a specific page...

Note, that's not true for rollback and patrol tokens. But for other tokens this does make sense.

(In reply to comment #5)

Since tokens are session specific rather than page specific, it doesn't make
sense that you have to tie your request for a token to a specific page...

Note, that's not true for rollback and patrol tokens. But for other tokens this
does make sense.

But I suppose those are done differently anyway :)

action=tokens&type=edit|delete|protect|move|block|unblock|email|import|watch ?

That looks good to me. And if no type is specified, it should return just an edit token.

john wrote:

Tokens module

Attached:

Bryan.TongMinh wrote:

Looks good, except that the token types should not be hardcoded into this module, but rather use ApiQueryInfo::getTokenTypes(), which should be made static.

john wrote:

The reason right now they're hardcoded is because by default the hook in that function expects the get*Token function will get a pageid and title. The point of this module is to be able to get tokens without needed a page(id), so unless we just pass a random page to satisfy tokens it doesn't seem a good idea to me.

Maybe we should just restructure the ApiQueryInfo module getToken functions to not need page info, but that's a bigger task and would warrent developer consenus.

(In reply to comment #10)

The reason right now they're hardcoded is because by default the hook in that
function expects the get*Token function will get a pageid and title. The point
of this module is to be able to get tokens without needed a page(id), so unless
we just pass a random page to satisfy tokens it doesn't seem a good idea to me.

Maybe we should just restructure the ApiQueryInfo module getToken functions to
not need page info, but that's a bigger task and would warrent developer
consenus.

I think Brian is possibly just meaning ApiQueryInfo->getTokenFunctions()

So that we're not hardcoding the token types, and keep it somewhat dynamic, so other modules can add their own without having to change the core modules...

Having said that, non of the getToken functions actually use either of the parameters....

john wrote:

(In reply to comment #11)

I think Brian is possibly just meaning ApiQueryInfo->getTokenFunctions()

Yup, I know.

So that we're not hardcoding the token types, and keep it somewhat dynamic, so
other modules can add their own without having to change the core modules...

The point is that if people are hooking into it right now their custom getToken functions are expecting a pageid and Title. Just blindly going with this and sending off null or a random page could have odd side effects

Having said that, non of the getToken functions actually use either of the
parameters....

Then maybe we should move those functions to ApiTokens create a new hook for tokens that don't need page info, and fix ApiQueryInfo to use that.

This seems to have stalled. I like John's solution as it covers 99% of use cases and is relatively straightforward. We can always add dynamic token types later (as the API syntax will still be the same). I don't see any reason to hold this up in the meantime.

Submitted patch as Change I58bc5847 (https://gerrit.wikimedia.org/r/#change,3890)

Added support for patrol tokens in Change I6efa13bd (https://gerrit.wikimedia.org/r/#change,3921)

I have a question here - currently the token is session-based, but if no longer bind the token to the target page (edit|delete|protect|move) or the user (block|unblock), aren't we losing possibility of ever introducing a notification/conflict resolution/etc. mechanism to notify ("someone is working on this right now") - kind of "soft advisory locking" on an object?

FlaggedRevs is trying to do this to show that somebody is reviewing the page right now.

a.d.bergi wrote:

(In reply to comment #16)
I think most of the actions you named are atomic, like moving a page. They won't need a notifiaction/conflict feature.
For longer-taking actions like editing or revFlagging, you usually first need to query the page content or revision diff before acting. In this step both token and notification etc. can be sent along.

But there are also exeptions. For example, adding a new section would be kind of atomic editing.
Also, tokens are currently session-based, as you said. Changing this to target-based would always be a compatibility break for applications, no matter how the tokens are requested.