I am using the following code to display a PDF document in an HTML element.
<embed src="PDFURL" type="application/pdf" width="100%" height="474px" />
Whenever the code is run in Firefox it works perfectly, however when run in Chrome it returns this error in the console:
"Failed to load 'PDFURL' as a plugin, because the frame into which the plugin is loading is sandboxed."
I have changing "embed" to "object" and "iframe" but neither have worked. Is there a solution to get it to work in Chrome?
One possible reason for this problem is the Content Security Policy “sandbox” header.
sandbox
Enables a sandbox for the requested resource similar to the iframe sandbox attribute. The sandbox applies a same origin policy, prevents popups, plugins and script execution is blocked.
(The whole description can be found under https://content-security-policy.com/)
Unfortunately, the only possible way to get this working is to remove the sandbox value from Content Security Policy. Because there is no possible value to enable plugins.
The sandbox header works the same way as the sandbox attribute for iframe. See also Flash not work in iframe within sandbox attribute
Related
I am currently displaying the spotfire web player link via simple html call and it is working fine when using the Mozilla Firefox browser but if trying to load on Chrome browser it fails to load and here is the error on the web player display on the link:
Failed to load application
Could not load localized labels
Could not load configuration
And here is the simple html call:
<object data="http://myHost/spotfire/wp/render" type="text/html" style="width:100%; height:1000px;">
Alternative Content
</object>
Any suggestion/comments TIA
I wonder if it has to do with Chrome's update to block cross-site scripting.
In your console do you get any errors describing Cross-site/samesite=none errors thrown?
I had a similar issue with Chrome when using Spotfires Javascript API and it only occurred in Chrome. Here is a Post regarding it.
The overall fix was an update to the Spotfire Server setting of SameSite.
You have to setup a registry key. I have a blog post on this.
https://datashoptalk.com/use-chrome-web-player/
I'm building a very simple component in Vue to preview PDF files and images in a modal.
I'm using Vue Boostrap's modal component. In the body of the modal I have the following line:
<embed :src="fileSrc" type="application/pdf" height="100%" width="100%">
fileSrc is a prop that the component receives.
When the modal is launched, the PDF visualizer doesn't show and Google Chrome emits a warning saying:
Flash is blocked on this page
I have allowed flash to be displayed on the page but still doesn't work.
If I remove the type="application/pdf" attribute and the fileSrc is a JPEG file, it shows up just fine.
I've also tried with the <object> tag with no luck.
What should I check? What am I missing?
Edit: Why is this question not a duplicate?
Because I wan't to be able to use the <embed> tag to support not only PDF but also images for previewing. The examples in this page work without enabling Flash and without warnings, so I should be able to reproduce this behavior.
I found the answer.
The files I was trying to display with the <embed> were being uploaded to a bucket in AWS S3. When uploading the files (with a PHP script), the Content-Type metadata needed to be set accordingly to the file (i.e. application/pdf for PDF files).
The files were being uploaded with a default Content-Type value, thus the browser didn't know what to do with it once placed in a <embed> tag (the Content-type is used to determine which plugin to choose to display).
I found this method to be very easy to implement as a generic file previewer.
I am attempting to embed one site into another site. I control both servers, which I will refer to here as "site1.com" (the site in the browser) and "site2.com" (the site I am trying to embed).
HTML embed code
Attempt 1, using iframe tag:
<iframe height="600" width="600" name="my other site"
src="https://site2.com/foo/bar">
Unable to display--your browser does not support frames.
</iframe>
Attempt 2, using object tag:
<object type="text/html" height="600" width="600" name="my other site"
data="https://site2.com/foo/bar"></object>
Things I know are not the problem
Secure/insecure mismatch
I've read that Firefox will not allow an HTTP embed into an HTTPS page. Both sites are HTTPS, so there is no mismatch. The loaded resources (CSS, etc) are also https, from same origin, so there is no mixed-content problem.
I have tried setting security.mixed_content.block_active_content to false, in case I was mistaken about this, but the iframe was still blank.
Invalid or untrusted certificates
Both sites are using valid certificates, signed by a proper trusted authority, and are not expired. In fact, we are using a subdomain wildcard certificate, so they are both using the same certificate (they both are in the same subdomain).
X-Frame-Options
The site that I am trying to embed has this response header:
X-Frame-Options: ALLOW-FROM SITE1.COM
Content-Security-Policy
The site that I am trying to embed has this response header (wrapped here for readability):
Content-Security-Policy:
frame-ancestors https://site1.com;
default-src 'self';
script-src https://site1.com 'self' 'unsafe-inline';
style-src https://site1.com 'self' 'unsafe-inline'
Extra disclosure, possibly not needed - these headers are being generated by a Django application server, using this config and the "django-csp" module.
X_FRAME_OPTIONS = 'Allow-From site1.com'
CSP_FRAME_ANCESTORS = ('https://site1.com',)
CSP_STYLE_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CSP_SCRIPT_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CORS
My understanding is that CORS is only in play when the request contains an "Origin" header. That doesn't seem to be happening here. I have also tried addressing CORS by using this header:
Access-Control-Allow-Origin: https://site1.com
But that appears to have no effect.
Ad blocker
I do not have an ad blocker in this Firefox install. I also removed all of my extensions and re-tested after a Firefox restart, the "blank iframe" behavior remains the same with no extensions installed at all.
Observed behavior
I have tested using the following browsers.
Google Chrome 58.0.3029.81 (64-bit) (macOS)
Safari 10.1 (macOS)
Firefox 53.0 (64-bit) (macOS)
Microsoft Edge 38.14393.0.0 (Windows 10)
Using Chrome, Safari, and Edge, the frame is shown like I expect - site2.com appears as a box inside of the site1.com page.
Using Firefox, I am shown an empty space of the size specified (600x600). If I used iframe, then there is a black border around it. If I used object, it's just a blank area with no border.
The most interesting thing is that if I open the developer console and reload the page, I see the requests to fetch site1.com and its CSS and so on, but there are no requests made for site2.com. It isn't that there is a problem showing site2.com, it is never requested at all.
Also, the developer console shows no errors or warnings about this. If there were an error condition or security exception preventing the loading of the second site, I would expect some sort of warning to be logged.
This has been driving me crazy for a few days. Any suggestions appreciated.
I reproduced the issue on my server which serves 2 domains, and then fixed it this way:
X-Frame-Options: ALLOW-FROM https://SITE1.COM
I added https://, as seen in MDN page for X-Frame-Options
You can observe the difference here (only with Firefox of course, as with other browsers both frames are shown): I pushed a php page that inserts the header without or with https://, and created this fiddle that insert 2 iframes: Firefox shows first iframe as empty, and second one with content (which echoes the value in header) on the right.
Since you are forced to put a "serialized origin" (protocol+FQDN), I wondered if you can put multiple entries, or wildcards. My understanding of RFC 7034 says you cannot.
Now about this detail:
The most interesting thing is that if I open the developer console and
reload the page, I see the requests to fetch site1.com and its CSS and
so on, but there are no requests made for site2.com. It isn't that
there is a problem showing site2.com, it is never requested at all.
That's because it was cached. I also saw that, but a force-refresh rightly showed a new request was made.
If you knew the source code (right click and view source of url to embed - but you control it in this case so you can copy and paste) and it was only a reasonably small amount of code (probable because you're using an iframe), then you could use the HTML5 srcdoc attribute to embed the html code, instead of pointing to the url. This would save a lot of hassle regarding unknown factors regarding the site you want to embed (CORS etc..) which you would not usually know if you didn't have control over the second site.
According to caniuse.com the srcdoc property has full support in Firefox since vsn 25 onwards (so since Sept 2013).
Hope this helps (Here's a tested jsfiddle example)
I'm trying to embed a Google Group into a web page on a site, but I cannot get it to work in all browsers and am stumped about why. Using the <iframe> and JavaScript code provided by the Google Groups configuration system, things work when I view the page in Safari (version 6.1, 8537.71) and Chrome (32.0.1700.107), but not FireFox (26.0) running on Mac OS X 10.8.5. Running FireFox's debug console reveals the following error:
Load denied by X-Frame-Options: https://groups.google.com/
does not permit framing by http://mysite.org/mypage
(where http://mysite.org/mypage is the actual page URL, of course). Now, the curious thing is that using the debug consoles in Chrome and Safari, they both report an error too—but it is about the X-Frame-Options header sent by Groups:
Invalid 'X-Frame-Options' header encountered when loading
'https://groups.google.com/forum/embed/?place=forum/myforum
&domain=mydomain.org&showtabs=false&parenturl=
http%3A%2F%2Fmydomain.org': 'ALLOW-FROM https://groups.google.com'
is not a recognized directive. The header will be ignored.
This seems to imply that the reason it works in Safari and Chrome is that Google is sending an invalid header (which seems unlikely) and Safari and Chrome therefore ignore it, or that both browsers are unable to interpret X-Frame-Options, which as far as I can tell, is not supposed to be the case.
Can anyone think of what might be going on, or suggest what other possible issues I can check for?
A past question on SO seemed to hit a similar or possibly the same problem, but the OP's problem apparently went away on its own, whereas mine persists whether I am logged in or out of my Google account.
EDIT 2014-02-06 #1
I've now determined that Chrome and Safari do not implement support for ALLOW-FROM in X-Frame-Options; that explains the messages in the consoles, and probably explains why those browsers do not block the embed Google Groups page. Also, if I interpret the definition of the ALLOW-FROM option correctly, the URI provided as the value should be the enclosing page; in other words, Google should be sending back ALLOW-FROM mydomain.org and not the value it is currently sending. I guess I must be doing something wrong, but I've followed exactly Google's instructions for setting up the iframe, including the part about supplying &domain=yourdomain.com.
EDIT 2014-02-06 #2
In view of the above, my original question is basically answered: the reason Safari and Chrome display the embedded page is that they currently ignore the security header value, whereas FireFox doesn't, and correctly blocks the embedding because the value of ALLOW-FROM is not the domain of the page enclosing the iframe (mydomain.org) as it needs to be.
So the question is now, why does Google set ALLOW-FROM to https://groups.google.com rather than mydomain.org.
EDIT 2014-02-06 #3
Solved. The reason that Google was sending the X-Frame-Options value is that my <iframe> code was incorrect. For reasons that I can no longer reconstruct at this time, I was led to believe that ampersands in the src attribute value needed to be escaped, like this:
<html><body>
<iframe id="forum_embed" src="javascript:void(0)"
scrolling="no" frameborder="0" width="746" height="1200">
</iframe>
<script type="text/javascript">
document.getElementById('forum_embed').src =
"https://groups.google.com/forum/embed/?place=forum/sbml-discuss"
+ "&parenturl=" + encodeURIComponent(window.location.href);
</script>
</body></html>
In fact, it does not work if written that way. But the following does:
<html><body>
<iframe id="forum_embed" src="javascript:void(0)"
scrolling="no" frameborder="0" width="746" height="1200">
</iframe>
<script type="text/javascript">
document.getElementById('forum_embed').src =
"https://groups.google.com/forum/embed/?place=forum/sbml-discuss"
+ "&parenturl=" + encodeURIComponent(window.location.href);
</script>
</body></html>
(The difference is in &parenturl.) And this is exactly what Google's instructions say to do. Which is, you know, really embarrasing....
This is controlled by the parentUrl url-param to the iframe src attribute.
It might just be the chrome console encoding it, but it looks like the URL for the iframe src has the '&' characters encoded.
Are you hardcoding the parentUrl attribute? or are you using 'encodeURIComponent(window.location.href)'
(from the help docs: https://support.google.com/groups/answer/1191206?hl=en)
I had the following iframe which renders the Video.In IE8, I am getting the security popup error.
<iframe src="https://fast.wistia.com/embed/iframe/223ewe311111112?videoWidth=310&videoHeight=120&controlsVisibleOnLoad=true&playerColor=1213221&plugin%5Bsocialbar%5D%5Bversion%5D=v1&plugin%5Bsocialbar%5D%5Bbuttons%5D=email-twitter-googlePlus-facebook&plugin%5Bsocialbar%5D%5Blogo%5D=true&plugin%5Bsocialbar%5D%5BtweetText%5D=May%20to%I%20New%Help%20You%20&plugin%5Bsocialbar%5D%5BbadgeUrl%5D=https%3A%2F%2Fwistia.com&plugin%5Bsocialbar%5D%5BbadgeImage%5D=https%3A%2F%2Fprime-cdn.wistia.com%2Fdeliveries%2Fe6e6be3fsdfsdfsdfsdf7e0a69.jpg%3Fimage_crop_resized%3D100x20" target="_blank" rel="nofollow" allowtransparency="true" frameborder="0" scrolling="no" class="wistia_embed" name="wistia_embed" width="310" height="120"></iframe>
I came to know that they updated their IFRAME API on their framework.Will it be a cause for rendering the popup in IE8 only.Using HTTPWATCH plugin in IE8,I found that all resources are rendering HTTPS only.So, because of this iframe tag only it is rendering the popup.I put this iframe tag in seperate HTML page and opened it in IE8 browser.It is showing Security popup.
First, you better get that example embed code checked out! :) It doesn't look like the iframe src is valid (it leads to a 404 page), which made this a little difficult to test. There are also some weirdnesses like target="_blank" on the iframe, which I don't think is produced by Wistia.
Anyway, I stapled the options onto a different media's embed code and I think I figured out your issue. The domain for the logo in the socialbar is what's causing the security warning.
If you upload your logo in the SuperEmbed Builder then switch to an SSL (under Embed Type > Advanced Options), it will also switch the domain of the logo to one that has a security certificate. I'm guessing that you produced a non-SSL embed, then manually switched it from http: to https:. In many cases this doesn't matter, but it does in this one unfortunately.
My recommendation is to produce the embed code directly from the SuperEmbed Builder and switch SSL on there.
What's the nature of the error you're getting? "Unsafe JavaScript attempt to access frame with URL [URL redacted] from frame with URL [URL redacted]. Domains, protocols and ports must match."
If so, there are a number of threads here at StackOverflow that also mention this error. while annoying, is extremely unlikely to be detrimental to how your site works, it's simply a symptom of having unmatched domains, ports and protocols between the iframe and page its embedded on.
So yeah, as long as the content on the page appears to be fine, you can most likely ignore that particular error.
As an alternative, try the Wistia API embed style, which you can also use SSL with--should help you avoid seeing this.