Find solution for content-security-policy configuration not being set correctly by the user.

[begedin]

Note: The information bellow is outdated. See #101 (comment) for recent information.

Copied from parent issue #100

By default, ember new app-name will create an app with ember-cli-content-security-policy as a dependency. The default app settings will prevent the application from running cause the application to throw errors due to several of the default content security policies being violated. The app will still run, but the console will be red.

The following settings are required to be present in the app's configuration file into the exported ENV object in order for the app to run without issues:

   contentSecurityPolicyHeader: 'Content-Security-Policy',
   contentSecurityPolicy: {
      'default-src': "'self' accounts.google.com content.googleapis.com drive.google.com",
      'script-src': "'self' 'unsafe-eval' 'unsafe-inline' apis.google.com drive.google.com",
      'font-src': "'self'",
      'connect-src': "'self' 'unsafe-eval' apis.google.com drive.google.com",
      'img-src': "'self' data: ssl.gstatic.com csi.gstatic.com",
      'style-src': "'self' 'unsafe-inline'",
      'media-src': "'self'"
    },

Potential solution

1. We could keep things as they are. Errors are thrown for each of these settings, so the user will be aware what's wrong for the most part. However, the minimal required settings are identical for any app using ember-gdrive, so ideally, we should find an automatic solution which wouldn't require user intervention.
2. The Blueprint.prototype (used to define a blueprint) has an insertIntoFile() method, which should be able to insert something into any file within the project folder, including the configuration file.
3. Maybe there's a more robust method somewhere which allows adding actual configuration properties to the configuration file. This would be preferable to number 2, but I'm not sure it actual exists. Addon.prototype.config could be our answer here, in which case, the configuration properties would be added to index.js, instead of through a prototype.

Conclusion

I believe this configuration setting group can and should be automated. I could spend some time trying to find out if option 3 is possible, but if not, option 2 is the way to go in my opinion.

[begedin]

@venkatd: Option 3 would be preferable here, of course, but even if it's not, I think it could be doable with option 2. Do you think this would be worth doing?

[venkatd]

@begedin I think option 2 would be the simplest for now. This also offers the benefit of allowing you to customize the policy if you need to add anything else to it.

[begedin]

Option 2 would be simpler, but I believe option 3 would allow us to either

• Create the entire security policy config group if no such thing exists in the configuration.
• Add to the existing config group if it's already present.

This would allow us to add our own things on the fly, without actually polluting the config file or the settings already present there. I think that might be worth exploring.

[venkatd]

Exploring option 3 is fine with me. Just be wary of spending too much time of option 3 if you see things aren't as simple as you expected.

[begedin]

@venkatd: I implemented option 3 in #107 and it works, but there are some concerns I listed in the pull request. Copied here for convenience:

I'm thinking this might be considered bad add-on behavior, since it basically opens up potential security issues without the user actually knowing this.

To elaborate, this will not change config\environment.js physically on the disk. Instead, it will add the rules required by the add-on into the config object in memory. It's way more robust than option 2 in the issue description, but as I said, there may be a security concern.

On the other hand, option 2 is more transparent, but also much less robust. It has to deal with all the same issues that pull request #106 has listed, slightly increased by the fact that there's more text to add in this one. That being said, I'm also leaning towards option 2 now and it should be a quick thing to abandon the current approach and implement it that way.

I guess the question here is, what is the intended use for for Content Security Policy. Based on the official spec, it's supposed to prevent security issues introduced through cross-site scripting, such as injection, etc. If that is the case, then option 3 is not bad add-on behavior and we should probably go with that.

What's your opinion?

[venkatd]

Is the content security policy something you see as the user needing to customize? If so, I think option 2 is better despite the fragility of it (we can improve the robustness of modifying the config file later). Otherwise, option 3 sounds good.

[begedin]

For any remote url the user is accessing in any way, an entry needs to be added to the content security policy settings, so yes, it does need to be customizable.

However, option 3 doesn't stop it from being customizable. The user can have their own settings in config/environment.js. The way this code is set up is that ember-gdrive will add to the existing settings instead of overwriting them.

The only uncertainty was whether an add-on should modify the content-security-policy and reading about what it's intended for (to prevent intrusion from remote sources, not to prevent us from accessing remote sources), I think that's not an uncertainty anymore.

Considering that, I think option 3 should be the way to go.