Page MenuHomePhabricator

API does not recognize I'm logged in
Closed, InvalidPublic

Description

Headers

While hacking on a script[1][2] for cross-wiki watchlists using CORS, I noticed the following problem:

  1. Open Google Chrome 36 (on Linux Mint 17)
  2. Clear the cache and cookies (shortcut: CTRL+SHIFT+delete)
  3. Access https://pt.wikipedia.org/wiki/Special:UserLogin?uselang=en&useskin=vector
  4. Log in
  5. Open the console (shortcut: CTRL+SHIFT+J)
  6. Execute an API request to Wiktionary:
$.ajax( {
	url: 'https://pt.wiktionary.org/w/api.php',
	xhrFields: { withCredentials: true },
	data: {
		action: 'query',
		format: 'json',
		list: 'watchlist',
		origin: 'https://pt.wikipedia.org'
	},
	dataType: 'json'
} )
.done( function( data ) {
	if ( data.error ) {
		console.warn( data.error.code + ': ' + data.error.info );
	} else {
		console.warn( 'ok' );
	}
} );

This results in "wlnotloggedin: You must be logged-in to have a watchlist".

Notes:

  • If I execute the same steps on Firefox 31, I get "ok".
  • If I access

https://pt.wiktionary.org/w/api.php?action=query&format=json&list=watchlist
directly in the browser, I get the data, without any error.

  • If I open https://pt.wiktionary.org/wiki/Special:Watchlist, I see the pages I'm watching, without any error.
  • If I replace "pt.wikipedia.org" by "en.wikipedia.org" on steps 3 and 6, the same error apears.
  • If I also replace "pt.wiktionary.org" by "en.wiktionary.org", then I get "ok".
  • If I use another account on pt.wikipedia.org, and reset my preferences before doing the request, I still get the error.

[1] https://github.com/legoktm/xwiki-watchlist/blob/master/xwikiwatchlist.js
[2] https://github.com/he7d3r/mw-gadget-CrossWikiWatchlist


Version: unspecified
Severity: normal

Attached:

Details

Reference
bz69028

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:29 AM
bzimport set Reference to bz69028.
bzimport added a subscriber: Unknown Object (MLST).

From #wikimedia-dev today:

<helderwiki> legoktm: could you try to reproduce this ^
<helderwiki> ?
<legoktm> helderwiki: looking
<legoktm> helderwiki: Chromium 38 on OSX I got "ok"
<legoktm> helderwiki: maybe it's just a race condition where the central login hasn't finished yet?
<helderwiki> legoktm: I don't know... it has been like that for a few minutes... and I even tried to log in directly from the target wiki, but it keeps saying I'm not logged in
<legoktm> helderwiki: does it happen just for watchlist or other API modules like meta=userinfo?
<helderwiki> legoktm: does that also requires the user to be logged in?
<legoktm> no, but it'll tell you whether you are or not
<helderwiki> hmm let me check
<legoktm> <userinfo id="3855926" name="Legoktm" />
<legoktm> <userinfo id="0" name="$ip" anon="" />
<helderwiki> legoktm: I get my IP in something like this: {id: 0, name: "999.999.999.999", anon: ""}
<legoktm> so it's just not logging you in :/
<helderwiki> legoktm: I used this: http://dpaste.com/3D71TG3
<helderwiki> and got the IP. Then I made the same request to en.wiktionary.org and got my username
<legoktm> :/
<legoktm> maybe brion might have an idea? ^
<brion> ?
<helderwiki> brion: see https://bugzilla.wikimedia.org/show_bug.cgi?id=69028
<brion> legoktm: if it’s with credentials i think it ought to work, though the way centralauth works now it might not
<legoktm> brion: helderwiki is having an issue with CORS not working for him from pt.wp --> pt.wikt
<legoktm> hm
<legoktm> brion: but even if he logged in directly to pt.wikt?
<brion> hmmmmmm that should work, as long as it’s not silently the request downgrading to jsonp
<brion> in which case auth would be disabled
<brion> helderwiki: what’s the exact request look like in debug console in the browser?
<helderwiki> I added an attachment to the bug, with the headers
<helderwiki> I think it is there too
<helderwiki> let me see
<brion> looking
<brion> yeah….. no callback or jsonp indicator….
<brion> helderwiki: were there any Cookie: lines that you removed manually from that?
<brion> cause it looks like it didn’t send any auth cookies
<brion> despite Access-Control-Allow-Credentials:true hmmmm
<brion> weird
<helderwiki> nope..
<helderwiki> Nemo_bis: if that question for me, the answer is no.
<helderwiki> also, I just tried google chrome 36 on windows xp and it works there
<helderwiki> and it works on Firefox too.
<helderwiki> brion, legoktm: similar requests to other portuguese wikis also fails: pt.wiktionary.org, pt.wikivoyage.org, pt.wikiversity.org, pt.wikisource.org, pt.wikiquote.org, pt.wikinews.org
<helderwiki> but it works for pt.wikibooks.org

<helderwiki> (always doing the requests in a page from pt.wikipedia.org)

It appears there is some sort of a bug in Chrome that is making it ignore the withCredentials flag. The API seems to be working fine.

If that is the case, I can't imagine a reason why such a bug would cause the requests to work with

  • pt.wikibooks.org
  • en.wiktionary.org
  • meta.wikimedia.org
  • incubator.wikimedia.org
  • www.wikidata.org
  • br.wikimedia.org

but fail with e.g.

  • pt.wikisource.org
  • fr.wikiquote.org
  • ru.wikibooks.org
  • zh.wikinews.org
  • wikisource.org

...

If someone can confirm that this is actually a Chrome bug (say, by sniffing the requests it actually sends), then we should probably file an upstream bug report.

Ok. I think it is my fault.
I had the option "Block third-party cookies and site data" enabled on Chrome, and for some reason there were exceptions like these in the list:
[*.]pt.wikibooks.org
[*.]meta.wikimedia.org
[*.]incubator.wikimedia.org
[*.]en.wikinews.org

It seems Chrome added the wikis I visited recently to the exception list, so this explains why the requests failed exactly when I was choosing "random" wikis which I didn't access recently, but worked for wikis I accessed.

The request to pt.wiktionary.org worked as soon as I changed the exception to "[*.]wiktionary.org" or disabled the option "Block third-party cookies and site data".

From what I can see, there is nothing to report to upstream either (right?).

Sorry for the trouble.

He7d3r set Security to None.