Hi Aryeh, thanks for answering!

2011/1/9 Aryeh Gregor Simetrical+wikilist@gmail.com:

2011/1/8 Jérémie Roquet arkanosis@gmail.com:

...

Both of them use a trick with an iframe to allow javascript requests across the wikipedia.org subdomains (something that is not possible using AJAX).

It would be possible if we started using CORS, at least in recent enough browsers.

It would be awesome to have this enabled to allow AJAX requests across all the Wikimedia projects. I mean, not only it would allow to make my tools work again without the iframe hack, but I have many other ideas of really cool new tools that could be built upon CORS (including interactions between Wikipedia and Wikimedia Commons, which I could not achieve with the iframe trick).

Sure, it wouldn't work in as many browsers as the iframe trick did, but I really prefer something that requires a modern browser to work to something that requires an old one ;-)

...

- Does anybody know if having X-Frame-Options set to SAMEORIGIN would allow such tricks while still preventing clickjacking attacks from other domains (the actual question is: `would it work'?)

en.wikipedia.org is not the same origin as fr.wikipedia.org.

True, but it appears that setting document.domain to the same value for both subdomains (ie. 'wikipedia.org') is enough to have the same origin. [1] That's what I was already doing for iKiwi and xmsg to work, because without this, most browsers already enforce the same origin policy for DOM manipulations inside (i)frames. With it, it works fine, even with the NoScript addon.

...

Any other idea on how to make such tools work again would of course be highly appreciated.

I'm not very knowledgeable in this sort of thing, I'm afraid.  HTML5's postMessage() might be useful.

Thanks for the tip, I never heard about this before. However, reading the description at MDN [2], I'm afraid it doesn't address the current issue at all because it requires two windows to communicate together (which is exactly what X-Frame-Options forbids). That would have allowed to make cross-domain requests (eg. between Wikipedia and Wikimedia Commons), but with X-Frame-Options I'm afraid it's just as useless as the iframe hack.

That said, my questions now are: - It would be very nice to have CORS enabled across the Wiki[mp]edia subdomains (I see it has been mentioned by Brion in the `JavaScript access to uploaded file contents' thread [3][4] for upload.wikimedia.org) ⇒ is it something that can be done / discussed? I looks like the code for this is already there [5], maybe I should open a new bug right now? - Taking the document.domain trick into account ⇒ would setting X-Frame-Options to SAMEORIGIN instead of DENY allow frames between /sub/domains?

Thanks again! Best regards,

[1] http://en.wikipedia.org/wiki/Same_origin_policy#Additional_document.domain_l... [2] https://developer.mozilla.org/en/dom/window.postmessage [3] http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/050972.html [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=25886 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=19907

2011/1/9 Roan Kattouw roan.kattouw@gmail.com:

2011/1/9 Jérémie Roquet arkanosis@gmail.com:

...

- It would be very nice to have CORS enabled across the Wiki[mp]edia subdomains (I see it has been mentioned by Brion in the `JavaScript access to uploaded file contents' thread [3][4] for upload.wikimedia.org) => is it something that can be done / discussed?

This has been discussed in a few contexts now, and we all seem to agree that this is a good idea and should definitely be enabled. I'd propose doing this after we deploy 1.17wmf1 and stuff has calmed down a bit (it's not uncommon for things to break after a major deployment).

Hi Roan. It's great if there's no major opposition to it :)

...

I looks like the code for this is already there [5], maybe I should open a new bug right now?

Would be nice to track it in BZ, yes.

Will do so and give the link there. Thanks!

2011/1/9 Aryeh Gregor Simetrical+wikilist@gmail.com:

I don't see any detailed documentation for X-Frame-Options anywhere. It looks like IE8 made it up with no detailed spec and other browsers copied the general idea still with no detailed spec. So I don't know, sorry.

No worries :) Thanks again.

2011/1/9 Ilmari Karonen nospam@vyznev.net:

...

Both of them use a trick with an iframe to allow javascript requests across the wikipedia.org subdomains (something that is not possible using AJAX).

Use JSONP. The MediaWiki API supports it through the "callback" parameter.

Hi Ilmari, great idea! It's not as powerful as the iframe hack was (since it's limited to the api), but I think it's enough for me to release a quick fix for iKiwi (not for xmsg, unfortunately, because userinfo is not accessible that way). I didn't know about the callback parameter, so you just saved my business ;-) Thanks a lot!

2011/1/10 Tim Starling tstarling@wikimedia.org:

On 10/01/11 01:23, Jérémie Roquet wrote:

...

• Taking the document.domain trick into account ⇒ would setting

X-Frame-Options to SAMEORIGIN instead of DENY allow frames between /sub/domains?

No, SAMEORIGIN does not allow framing from say en.wikipedia.org to fr.wikipedia.org. It only allows framing within the exact same domain. http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjac...

Hi Tim, thanks for the link and the explanations!

Hi Platonides,

2011/1/10 Platonides Platonides@gmail.com:

Jérémie Roquet wrote:

...

It's  not as powerful as the iframe hack was (since it's limited to the api), but I think it's enough for me to release a quick fix for iKiwi (not for xmsg, unfortunately, because userinfo is not accessible that way).

Why do you consider the api less powerful than "dom scraping" ? What can't you do with it?

Well, it's not an issue about the api per se, but rather a weakness of the jsonp approach: - You can't fetch user-specific data [1] - You can't send POST requests, meaning you can't edit or create pages [2] Both limitations are of course fortunate because it would allow malicious sites to know about their visitors or to edit Wikipedia on their behalf.

It fits perfectly for fetching the interwikis: http://en.wikipedia.org/w/api.php?action=parse&page=Main_Page&prop=l...

Yes, that's the good point. I'm very happy Ilmari came with the jsonp idea as it's exactly what I need for iKiwi to work again. And thanks for the langlinks idea!

And there's a handy property to determine if you have new messages: http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=...

Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].

Hopefully, with CORS we'll have access to the whole api (including userinfo and writeapi) (and to scrapping, if needed for any reason).

Thanks for your ideas! Best regards,

[1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » — [2] « action=edit * Create and edit pages. [...] This module only accepts POST requests. »

Ilmari Karonen wrote:

On 01/11/2011 11:59 AM, Jérémie Roquet wrote:

...

...

And there's a handy property to determine if you have new messages: http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=...

Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].

[1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » —

Hmm, true. You might be able to emulate the functionality by using prop=info on the user's talk page (and perhaps storing the last time the user visited the page in a cookie).

(Ps. It strikes me that the simplest and most efficient way to implement cross-wiki user talk notifications would be as a MediaWiki extension. Why do we not have one already?)

Nobody has written it yet. It would be like GlobalUsage. One big table listing data from all wikis. Although it should be able to take advantage from CentralAuth, adding a field into localuser table.

Jérémie Roquet á écrit:

2011/1/11 Ilmari Karonen nospam@vyznev.net:

...

On 01/11/2011 11:59 AM, Jérémie Roquet wrote:

...

...

And there's a handy property to determine if you have new messages: http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=...

Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].

[1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » —

Hmm, true. You might be able to emulate the functionality by using prop=info on the user's talk page (and perhaps storing the last time the user visited the page in a cookie).

Hi again. Sorry for the late reply (as I read most of wikitech-l threads in batch, I missed that one after the subject change).

Yes, that's a good idea and I think I'll do something like this. Thanks!

...

(Ps. It strikes me that the simplest and most efficient way to implement cross-wiki user talk notifications would be as a MediaWiki extension. Why do we not have one already?)

Sure. It would be both far more efficient and easier to set up. I guess I should really dive into MediaWiki development…

Best regards,

Feel free to send us patches. :) See my previous message about using CentralAuth for that. CentralAuth extension is not really an entry level extension, but you may have luck since you would just be adding hooks.

On Mon, Jan 17, 2011 at 3:58 PM, Happy-melon happy-melon@live.com wrote:

"Platonides" platonides@gmail.com wrote in message news:4D34A033.9080402@gmail.com...

...

CentralAuth is not really an entry level extension, but you may have luck since you would just be adding hooks.

Now there's the understatement of the week...

:-D

--HM

"Glue! I need Glue!"

2011/1/17 Platonides platonides@gmail.com:

Jérémie Roquet á écrit:

...

I guess I should really dive into MediaWiki development…

Feel free to send us patches. :) See my previous message about using CentralAuth for that. CentralAuth extension is not really an entry level extension, but you may have luck since you would just be adding hooks.

Yeah, thanks for the clues :-)

On 10/01/11 01:23, Jérémie Roquet wrote:

• Taking the document.domain trick into account ⇒ would setting

X-Frame-Options to SAMEORIGIN instead of DENY allow frames between /sub/domains?

No, SAMEORIGIN does not allow framing from say en.wikipedia.org to fr.wikipedia.org. It only allows framing within the exact same domain.

http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjac...

"For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin."

-- Tim Starling