Last modified: 2014-01-29 20:22:53 UTC
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>' 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" 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+\\"}}
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.
(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+\\"}}
(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.
