Last modified: 2013-06-16 18:58:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27886, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25886 - Make bits.wikimedia.org Cross-Origin Resource Sharing (CORS) compatible
Make bits.wikimedia.org Cross-Origin Resource Sharing (CORS) compatible
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal normal (vote)
: 1.22.0 release
Assigned To: Derk-Jan Hartman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-11 16:22 UTC by Derk-Jan Hartman
Modified: 2013-06-16 18:58 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Derk-Jan Hartman 2010-11-11 16:22:48 UTC
Because bits.wikimedia.org is a separate domain, in Opera and Firefox, i'm no longer able to access document.styleSheets.

See Cross Origin Resource Sharing: http://www.w3.org/TR/access-control/
Comment 1 Platonides 2010-11-11 16:36:24 UTC
I think you should be able to access document.styleSheets but not to its items?
Comment 2 Derk-Jan Hartman 2010-11-11 16:37:07 UTC
correct cssRules and the other elements that are cross domain protected.
Comment 3 Derk-Jan Hartman 2010-11-12 17:11:51 UTC
I think this could be solved by simply adding the header:

Access-Control-Allow-Origin: *

to all bits.wikimedia.org requests ? Unless we have non-public data that comes from that server, but I doubt that such data uses the bits server, because it would not be cache-able.

Geoiplookup has a similar security issue I guess, but that does carry sensitive data, and thus needs specific Origin targeting (API has this I believe).
Comment 4 Mark A. Hershberger 2011-02-08 20:46:19 UTC
Giving this to Ashar so he can poke his head in.
Comment 5 Antoine "hashar" Musso (WMF) 2011-02-16 20:03:01 UTC
Acknowledging assignment. I have to:
- learn about access control
- figure out what exactly need to be changed on the cluster
- get that reviewed
- do the change and test it :-)
Comment 6 Platonides 2011-02-16 22:33:19 UTC
Ashar, don't forget to have in list assessing in what ways could a given configuration be abused.
Comment 7 Bawolff (Brian Wolff) 2011-02-17 00:39:50 UTC
Also, the code in skins/common/diff.js accesses stylesheets using js on some browsers, is said code currently broken because of this?
Comment 8 Derk-Jan Hartman 2011-02-17 00:44:19 UTC
That code is only for really old gecko browsers. 20021130  november 2002. those browsers didn't have cross domain protection yet.
Comment 9 Antoine "hashar" Musso (WMF) 2011-11-19 16:43:34 UTC
Un assigning myself. I did not looked at that one for 7 months and I am not going to fix it anytime soon anyway.
Comment 10 Krinkle 2011-12-13 20:33:59 UTC
(changing bug to match search phrase "CORS")
Comment 11 Krinkle 2012-09-18 13:50:04 UTC
(In reply to comment #3)
> I think this could be solved by simply adding the header:
> 
> Access-Control-Allow-Origin: *
> 
> to all bits.wikimedia.org requests ? Unless we have non-public data that comes
> from that server, but I doubt that such data uses the bits server, because it
> would not be cache-able.
> 
> Geoiplookup has a similar security issue I guess, but that does carry sensitive
> data, and thus needs specific Origin targeting (API has this I believe).

bits.wikimedia.org should be restricted the same way as the API.

Though on second thought:

* /geoiplookup
  - Easily worked around, there are many public IP-to-location systems out there. The IP itself is not easily retrievable except with another domain available. We probably shouldn't be that domain.

* /../load.php: Modules can be private (e.g. user.options contains preferences), however these are already protected in load.php (e.g. try https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&modules=user.options&only=scripts). Private modules can only be loaded from server output.
Comment 12 Roan Kattouw 2012-11-11 01:32:41 UTC
(In reply to comment #11)
> * /../load.php: Modules can be private (e.g. user.options contains
> preferences), however these are already protected in load.php (e.g. try
> https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&modules=user.options&only=scripts).
> Private modules can only be loaded from server output.
Most of what load.php serves is JavaScript, which doesn't need CORS. The only thing I can see load.php remotely needing CORS for is CSS in only=styles requests. We can safely serve ACAO:* for those from within ResourceLoader. All other load.php requests should not use CORS. Geoiplookup also should not use CORS.

Static resources can be served with ACAO:* as well.
Comment 13 Gerrit Notification Bot 2013-04-21 14:48:21 UTC
Related URL: https://gerrit.wikimedia.org/r/60200 (Gerrit Change I8e05c13ae1a1589fd120d5c439b1a7128ce2b659)
Comment 14 Krinkle 2013-04-30 00:59:33 UTC
(moving bug from Wikimedia site requests to MediaWiki core)

Though I don't see a problem with this change (I8e05c13ae1a1), could you provide one or more use cases for accessing document.styleSheets in a MediaWiki context (just for future reference, I can imagine many use cases, but I'd like to know what TheDJ was doing).

Not blocking merge however, just curiosity.
Comment 15 Derk-Jan Hartman 2013-04-30 09:45:34 UTC
Personally, I was flipping the media attributes of stylerules, to manipulate the output of printing. My script allowed you to print 'what you see' for instance, instead of always printing with the 'print style'. This was a incidental request by users by en.wp users. There have been a few other cases (dynamically removing style rules when you no longer need them as a script was another one if I remember correctly).

My script (with this function currently disabled because it isn't working without CORS): [[User:TheDJ/printdialog]]

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links