Note: I also observed different behavior for different users on test2wiki. For example, Jeff's user would authenticate correctly via the API, but the Selenium_user or the Cmcmahon user would login and then receive the anonymous edit token, using exactly the same code.

Could you get the HTTP response headers? Wondering if the query could be cached at varnish level though POST response should definitely not be cached.

jhall wrote:

(In reply to comment #2)

Could you get the HTTP response headers? Wondering if the query could be
cached at varnish level though POST response should definitely not be cached.

Response headers obtained from step #3 of the original repro case above are:

Jeffrey-Hall:~ jeffreyhall$ curl -Ib cookies.txt -X POST "http://en.wikipedia.beta.wmflabs.org/w/api.php?action=tokens&type=edit&format=json"
HTTP/1.1 200 OK
Server: Apache
X-Powered-By: PHP/5.3.10-1ubuntu3.9+wmf1
X-Content-Type-Options: nosniff
Cache-control: private
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
X-Vary-Options: Accept-Encoding;list-contains=gzip
Content-Type: application/json; charset=utf-8
X-Varnish: 1847808099, 173965067
Via: 1.1 varnish, 1.1 varnish
Content-Length: 30
Accept-Ranges: bytes
Date: Sat, 25 Jan 2014 00:36:07 GMT
Age: 0
Connection: keep-alive
X-Cache: deployment-cache-text1 miss (0), deployment-cache-text1 frontend miss (0)

(In reply to comment #0)

In developing some test setup/teardown methods via the Mediawiki API, we have
noticed that en.wikipedia.beta.wmflabs.org (beta labs) always returns an
anonymous edit token, even following a successful login. This does not
happen
in other environments - in other environments, the edit API action is
authenticated as expected.

Repro workflow:

1. Request login token: curl -c cookies.txt -X POST

'http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=login&format=json&lgname=<username>&lgpassword=<password>&lgtoken=
'

2. Submit login token: curl -b cookies.txt -X POST

'http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=login&format=json&lgname=<username>&lgpassword=<password>&lgtoken=
<token
obtained in previous step>'

Here, you need to keep writing new cookies into cookies.txt. If the account is global, you'll get a centralauth_Session cookie with your new session id. If the account is local only, the session id is changed on login to prevent session fixation.

3. Request edit token, reusing the same cookie obtained above: curl -b

cookies.txt -X POST
"http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=tokens&type=edit&format=json"

When I call this, returning the CentralAuth session cookie that I got on step #2, I get a valid user edit token.

Response to step #3 is an anonymous edit token:
{"tokens":{"edittoken":"+\\"}}

In other environments, such as test2.wikipedia.org, the response in step #3
is
something like the following, which is the expected behavior (a valid edit
token is returned):
{"tokens":{"edittoken":"5d75e6ca92d6de881921f068ebd7b695+\\"}}

jhall wrote:

(In reply to comment #4)

(In reply to comment #0)

In developing some test setup/teardown methods via the Mediawiki API, we have
noticed that en.wikipedia.beta.wmflabs.org (beta labs) always returns an
anonymous edit token, even following a successful login. This does not
happen
in other environments - in other environments, the edit API action is
authenticated as expected.

Repro workflow:

1. Request login token: curl -c cookies.txt -X POST

'http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=login&format=json&lgname=<username>&lgpassword=<password>&lgtoken=
'

2. Submit login token: curl -b cookies.txt -X POST

'http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=login&format=json&lgname=<username>&lgpassword=<password>&lgtoken=
<token
obtained in previous step>'

Here, you need to keep writing new cookies into cookies.txt. If the account
is
global, you'll get a centralauth_Session cookie with your new session id. If
the account is local only, the session id is changed on login to prevent
session fixation.

3. Request edit token, reusing the same cookie obtained above: curl -b

cookies.txt -X POST
"http://en.wikipedia.beta.wmflabs.org/w/api.
php?action=tokens&type=edit&format=json"

When I call this, returning the CentralAuth session cookie that I got on step
#2, I get a valid user edit token.

Response to step #3 is an anonymous edit token:
{"tokens":{"edittoken":"+\\"}}

In other environments, such as test2.wikipedia.org, the response in step #3
is
something like the following, which is the expected behavior (a valid edit
token is returned):
{"tokens":{"edittoken":"5d75e6ca92d6de881921f068ebd7b695+\\"}}

Thanks Chris! This makes perfect sense and works as advertised. You the man!

Resolving bug since Chris has proved that it's not actually a bug; just stupid user error on my part.