Reputation: 21
In light of this link , it would seem inline scripts such as are used for inserting a recaptcha object in the page, via
<script type="text/javascript"
src="http://www.google.com/recaptcha/api/challenge?k=your_public_key">
</script>
<noscript>
<iframe src="http://www.google.com/recaptcha/api/noscript?k=your_public_key"
height="300" width="500" frameborder="0"></iframe><br>
<textarea name="recaptcha_challenge_field" rows="3" cols="40">
</textarea>
<input type="hidden" name="recaptcha_response_field"
value="manual_challenge">
</noscript>
or via
<script type="text/javascript" src="http://www.google.com/recaptcha/api/js/recaptcha_ajax.js"></script>
with
Recaptcha.create("your_public_key",
"element_id",
{
theme: "red",
callback: Recaptcha.focus_response_field
}
);
I always get some complaint about the content security policy, despite my manifest.json apparently allowing urls' like http://www.google.com/recaptcha/api/js/recaptcha_ajax.js
Am I missing something really obvious that makes this whole question crazy?
Upvotes: 2
Views: 7883
Reputation: 1178
You should make all your resource calls protocol relative urls. Basically remove any http: or https: and just use //
More info here http://www.paulirish.com/2010/the-protocol-relative-url/
and here Is it valid to replace http:// with // in a <script src="http://...">?
Upvotes: 0
Reputation: 4311
I just spent two hours fighting with this. For me, and I think for this example as well, the problem lies in the src
attribute; that is, in the http:
. Changing the references as follows:
<script type="text/javascript"
src="https://www.google.com/recaptcha/api/challenge?k=your_public_key">
^ v
<iframe src="https://www.google.com/recaptcha/api/noscript?k=
height="300" width="500" frameborder="0"></iframe>
fixed the problem. Basically, you're attempting to access the google api with an unsecure connection, and certain browsers (e.g., Chrome) don't render insecure content by default.
Upvotes: 4
Reputation: 349132
In a Chrome extension, the non-secure http
cannot be whitelisted via the CSP.
The documentation states:
Relaxing the default policy
(...) If, on the other hand, you have a need for some external JavaScript or object resources, you can relax the policy to a limited extent by whitelisting specific HTTPS origins from which scripts should be accepted. Whitelisting insecure HTTP resources will have no effect. This is intentional, because we want to ensure that executable resources loaded with an extension's elevated permissions is exactly the resource you expect, and hasn't been replaced by an active network attacker. As man-in-the-middle attacks are both trivial and undetectable over HTTP, only HTTPS origins will be accepted.
Upvotes: 1