Don't inject applications when CSP conflicts about privly-safari HOT 8 CLOSED

For detecting if the CSP allows the iframe to load, we can inject the iframe first and then, use the iframe.onload function to get to know whether CSP allows to inject the iframe in the host page. If the injection is not supported, the iframe then is removed. I am currently working on this and will link this issue to the PR soon.

from privly-safari.

I think it would be better to examine headers directly.

from privly-safari.

We cannot examine the headers in Safari. In chrome, this can be done using chrome.webRequest but, in Safari there is no corresponding API to do the same.

from privly-safari.

What about an AJAX request to the domain's robots.txt? That should allow you to check the headers, no?

from privly-safari.

Do you mean reading the domain's robots.txt? In that case, no. This can be seen at, https://twitter.com/robots.txt

from privly-safari.

from privly-safari.

I tried sending an XMLHttpRequest to the robots.txt for https://twitter.com, however, when the getAllResponseHeaders() function was called, the output was,
x-response-time: 206
Date: Fri, 21 Aug 2015 23:37:16 GMT
Content-Encoding: gzip
Server: tsa_k
Strict-Transport-Security: max-age=631138519
Content-Type: text/plain;charset=utf-8
x-connection-hash: 17a962ba74892c8fc7a1c2cf6f4e22cc
Content-Length: 472
This above output does not contain any information about CSP.

from privly-safari.

It looks like the offending header is only sent for the initial request. I don't like performing an iframe injection experiment for every page load, but let's move forward with a solution we have instead of trying to find the best solution.

from privly-safari.