Page MenuHomePhabricator

Change Content Security Policy on betacommons to allow api.flickr.com
Closed, ResolvedPublic

Description

Required to test Flickr import features of UploadWizard on beta.

Event Timeline

Urbanecm subscribed.

IIRC, neither beta nor production allow external non-WM-hosted service in their CSPs. This should not be done without SecTeam's affirmative comment.

sbassett triaged this task as Medium priority.Apr 6 2020, 3:47 PM
sbassett moved this task from Incoming to Watching on the Security-Team board.
sbassett subscribed.

Ideally, the Security-Team would prefer to wait for c557581 to get merged, so this sort of thing can fall to user-land, as I'm not sure everyone wants to or should allow something like api.flickr.com on beta or regular commons. Unfortunately, that patch is still hung up on RFC finalization (T208188#6030030). If this is more pressing, we could perhaps explore something like changing a CSP directive for a given time period (i.e. a day or two) to facilitate testing.

Note, the flickr thing is part of the uploadwizard extension, not a gadget or anything like that. Most of the other things like that had builtin exceptions, at least in the short term (in the spirit of stabilizing the status quo before changing things)

IIRC, neither beta nor production allow external non-WM-hosted service in their CSPs. This should not be done without SecTeam's affirmative comment.

So how come that Flickr import works on production but doesn't work on beta? (note: it works on beta when you disable CSP locally.. which is a very bad idea)

CSP is still being tested. Its enforced on beta for testing purposes, in prod it only gives warning on browser developer console

CSP is still being tested. Its enforced on beta for testing purposes, in prod it only gives warning on browser developer console

I believe VisualFileChange loads a resource from dewiki so that may cause problems too?

Note, the flickr thing is part of the uploadwizard extension, not a gadget or anything like that. Most of the other things like that had builtin exceptions, at least in the short term (in the spirit of stabilizing the status quo before changing things)

I'm not seeing anything in the labs CS.php/IS.php for anything outside of the standard Wikimedia domains, nor in the headers when I load any beta pages.

I believe VisualFileChange loads a resource from dewiki so that may cause problems too?

This should be fine as Wikimedia domains are already supported.

Note, the flickr thing is part of the uploadwizard extension, not a gadget or anything like that. Most of the other things like that had builtin exceptions, at least in the short term (in the spirit of stabilizing the status quo before changing things)

I'm not seeing anything in the labs CS.php/IS.php for anything outside of the standard Wikimedia domains, nor in the headers when I load any beta pages.

3rd party Maps on wiki en.wikivoyage would be one of such exceptions.

sbassett claimed this task.
sbassett moved this task from Backlog to Done on the ContentSecurityPolicy board.

This is currently allowed under the enforcing CSP within both Wikimedia production and the beta cluster. But that may not always be the case. Regardless, this is an exception that will likely always require some kind of work-around.