1

I'm currently trying to develop a chrome extension which is supposed to display data from different Jenkins servers. The url to the jenkins server is being entered by the user.

So basically what I need is being able to access any kind of jenkins url.

My problem is that Chrome's Content Security Policy only allows you to access domains which you've registered in the manifest.json like so:

"content_security_policy": "script-src 'self' http://localhost:8080/; object-src 'self'".

But since different users are going to enter different urls, I'd need to be able to change this policy dynamically, and I don't really know how to do that.

guyyst
  • 388
  • 1
  • 4
  • 16

2 Answers2

0

You won't be able to dynamically change the manifest once the extension has been installed. Per Google https://developer.chrome.com/extensions/contentSecurityPolicy#relaxing-remote-script :

Generic wildcards such as https:, https://* and https://.com are not allowed; subdomain wildcards such as https://.example.com are allowed.

If you could ensure that the CI machines are all on same domain then it could work.

peterdotjs
  • 1,526
  • 1
  • 13
  • 19
  • If you aren't able to register domains dynamically after installation, then there must be some other way to get JSON data from a nonspecific domain: https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo This extension allows you to enter any JSON url and displays the data without any problems. – guyyst Mar 05 '15 at 21:15
  • @guyyst I looked into the code of the rest client extension and they appear to be using [``](https://developer.chrome.com/extensions/match_patterns) permission. – peterdotjs Mar 11 '15 at 00:36
0

You seem have a misconception as to what is needed to send a request to a random domain.

CSP directive script-src dictates where you can execute code from specifically by <script src="https://some.domain/script.js">. That, indeed, is something you can't whitelist.

To send GET/POST cross-site requests, you need a host permission, not a CSP modification.

There are 2 possible approaches:

  • Give yourself wide permissions, e.g. "*://*/*" or "<all_urls>". This will allow you to query anything at the cost of install-time warning "can read and modify data on all websites".

  • Use the optional permissions API. That way, you can avoid the install-time warning and prompt for elevated permissions as the extension is configured. This would make sense if this configuration needs to be done infrequently.

    Extra note: as of 2016-10-04, permissions API is not implemented in Firefox WebExtensions / Edge Extensions, so if portability is a concern, it's best avoided for new projects for now.

Xan
  • 74,770
  • 16
  • 179
  • 206
  • Thanks for answering my almost 2 year old question :D But yes, you're right. I ended up going with the first solution you posted. Giving the all_urls permission. Having that warning wasn't really a problem for this project, since it was only for a small contest held by my school. – guyyst Oct 04 '16 at 21:08
  • Welcome! It was edited relatively recently and the existing answer isn't good. – Xan Oct 04 '16 at 21:09
  • Oh yeah, I think I looked at this a couple days ago by accident and found a spelling error. Couldn't let that go :p – guyyst Oct 04 '16 at 21:10