Last modified: 2014-08-02 00:36:20 UTC
Created attachment 16123 [details] 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://pt.wikibooks.org/wiki/User:Helder.wiki/Tools/Cross-Wiki_Watchlist.js
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.
