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.
Related
I am trying to embed an iframe (containing shellinabox, if that's relevant) onto an HTTPS webpage. The HTML I'm using to embed the iframe is pretty straightforward:
<div class="jumbotron" style="min-height: 400px;">
<iframe src="https://example.com/shellinabox" style="border:none; min-height: 400px;" width="100%"></iframe>
</div>
However, Chrome blocks the iframe from loading because it is "insecure content," and I have to manually unblock it for it to work. The Chrome console reports an error like this:
Mixed Content: The page at 'https://example.com/mainpage/' was loaded over HTTPS, but requested an insecure resource 'http://example.com/shellinabox/'. This request has been blocked; the content must be served over HTTPS.
I am confused by this because clearly my HTML code is embedding the HTTPS version of example.com/shellinabox. Moreover, when I visit https://example.com/shellinabox directly, the lock icon is green, nothing is blocked, and there are no indications of any SSL problems on that page.
I also tested this in Firefox, IE, and MS edge, and they all have the same behavior (so it's not a Chrome-specific issue). What gives?
This is an old question but I encountered the same issue. My use case is slighty different to yours, but hopefully this helps.
For me, my route on my python flask server ended with the "/" character. In my iframe, I was calling the route without the slash at the end of the src and was seeing the same error. Adding a slash to the src in the iframe did the trick for me.
<iframe src="https://example.com/shellinabox/" style="border:none; min-height: 400px;" width="100%"></iframe>
I'm not exactly sure why the missing slash on the end the src attribute would cause this error. If anyone can explain why, I'll gladly update my answer.
your code is loading the page over https but that page is then probably trying to load additional scripts or assets over http. or it may have scripts in the page that are making ajax requests over http. youll have to examine the page and look in the developer console to see exactly what the insecure requests are. it's probably not an issue with how you are creating the iframe element.
I have simple html code:
<iframe src="http://public.bullhornstaffing.com" width="500" height="700"></iframe>
<iframe src="http://public.bullhornstaffing.com/JobBoard/Standard/default.cfm?privateLabelID=9076" width="500" height="700"></iframe>
The first iframe displayed excellent in all browsers, but second iframe isn't displayed in IE instead of the page I see the text "Site Not Found. The site your are trying to find does not exist."
But when I try to open iframe url in the browser directly - everything works as it is necessary.
There is method to correct it?
The URL of the second iframe gets redirected to http://public.bullhornstaffing.com/JobBoard/Standard/BHContent_JobOpportunities.cfm and for some reason, the server responds to it differently when accessed on IE via iframe (or otherwise as embedded). What you get is technically a normal server response, just with special content.
It is at the discretion of server admin to do such things, e.g. in an attempt at preventing framing, though this behavior might be unintentional. Contact the server admin.
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'm working on a site that requires a login and includes embedded Youtube videos. Because of the login, I need to get SSL working, which it largely is. I'm hitting an unexpected problem with the Youtube embeds, though. It's easy enough to point at https://www.youtube.com, but Firefox still complains that there's unencrypted content on an encrypted page. According to Firebug, the only unencrypted load was from http://[stuff].youtube.com/videoplayback?[more stuff].
Now, it's perfectly understandable that Youtube doesn't want the overhead of encrypting their video streams, and I don't think that this poses an actual security vulnerability. I just need to keep the browser happy. (I know that that warning can be disabled, of course, but I can't do that on my users' machines.) There must be a way to do this, because https://www.youtube.com itself doesn't make this error pop up, even though it uses http: for the video streams, too.
I have not seen similar errors in other browsers, but I haven't looked very hard just yet.
If it matters, my development machine doesn't have a valid SSL certificate; I just added an exception.
If you are using <iframe> use <embed> or check other embedding code options that YouTube API provides.
I have a ssl secured website and this works for me in Firefox
<iframe id="player" src="https://www.youtube.com/embed/XfI....Ctpo?enablejsapi=1&origin=https://yourdomain.com&showinfo=0&iv_load_policy=3&modestbranding=1&theme=light&color=white&rel=0" frameborder="0"></iframe>
I don't have a solution, but a suggestion instead: Are you sure not having a valid SSL certificate couldn't have something to do with this? You wouldn't think so, but you never know. If you get one, and it still doesn't work, it's not something you wouldn't have had to do anyway. I went through the process of obtaining/installing and configuring SSL key(s) and certificates for my home server, and every little thing seems to have an impact on how SSL acts/reacts.
Also, have you tried accessing the site outside of the local network it's on? It sounds like you're on the same network as the server which is hosting the site (the one that has SSL installed), which can create problems itself because of NAT traversal (I believe, but correct me if I'm wrong - we're all here to learn). Sometimes with HTTPS, you can have a problem connecting to resources within the local network, that people on the internet would have no problem at all connecting to. Just my two cents.. and sorry for any incorrect info, if I provided any. Take this all with a grain of salt, but hopefully you'll find the answer to your problem. Things like this can be a pain in the rump.
There may not be anything you can do about this, also.. because Youtube seems to not provide content over HTTPS... which is out of your control. I know you don't contest the error you're being given, and just want a workaround, however.
BTW, I think their homepage is HTTPS enabled, just not their video content...so that's why embedding the homepage wouldn't produce the error.
EDIT: Also, I see someone else wrote to use embed instead of iframes, which I would also recommend. The browser treats iframes like another page, but the error your getting indicates the unsecure content is actually combined with the secure content, so everything should be fine with that... but you never know.
Try the page with the Firefox "inspector / network ananlysis" (shift-ctrl-I) to analyze what elements are requested. I guess it's some javascript INSIDE the that you don't have under your control. In any case you should be able to pinpoint the specific trigger with this tool.
Check wheter it makes a difference when switching your browser to HTML5 instead of Flash for the video or vice versa. YouTube recently changed the default protocol to HTML5.
Is it possible by your website design that you could try fetching the youtube videos by an http call instead of an https? I don't know the layout of your site, but if you're just wanting it to stop complaining, that should do it.
That said, youtube DOES have valid https certificates, but that's due to the google integration. Since you aren't google, you wouldn't read as the valid certificate holder when accessing youtube's content (that's the exact kind of thing SSL's are meant to guard against).
So, basically, if you can, just embed via http instead of https. YOUR site can still be https, just not the call to youtube.
Please remove http then u check..
for example
<iframe id="player" src="www.youtube.com/embed/XfI....Ctpo?enablejsapi=1&origin=https://yourdomain.com&showinfo=0&iv_load_policy=3&modestbranding=1&theme=light&color=white&rel=0" frameborder="0"></iframe>
just remove ( http or https ) with colon, it will work perfectly
example
<iframe id="player" src="//www.youtube.com/embed/XfI....Ctpo?enablejsapi=1&origin=https://yourdomain.com&showinfo=0&iv_load_policy=3&modestbranding=1&theme=light&color=white&rel=0" frameborder="0"></iframe>
A much simpler way to do this is to download the video itself and then link to it locally on your server e.g save it in the same directory as your page and then just link to it there.
I want to have two facebook pages open at the same time as part of my html page.
So when you go to mypage.html, there will be displayed two facebook pages. Is this possible?
I get something like:
with code like:
<frameset cols="25%,75%">
or
<iframe height="*" src="http://www.facebook.com/photo.php?fbid=10150277739848763&set=pu.105012493762&type=1&theater" width="100%">
<p>Your browser does not support iframes.</p> </iframe>
I work on Facebook's security team and actually helped write the code that causes this. We do this (a form of frame busting) to prevent clickjacking attacks where an attacker can put Facebook in an iframe, hide it, and trick the user into clicking in the facebook frame and taking some action (e.g. posting a malicious link to their profile, etc).
While Jason's answer is going in the right direction, it's not true that browsers will give you access to the DOM of a page you insert in an iframe in your page. The Same Origin Policy dictates that javascript on one domain cannot access anything on a page on a different domain.
Facebook prevents you from linking directly to the actual site via IFRAME (or any frame). This is because any site putting Facebook in an IFRAME(or any frame) could use Javascript to access elements of the facebook page, including username and password fields.
There is no way around this. It is built in to the browsers themselves to send some information along in the request header that says it is being requested to be put in frame.
Gmail and several other sites do this as well.
There are specific situations where overriding the "x-frame-options" security policy is useful, such as in digital signage where it is desirable to show an organization's facebook page in a iframe alongside other signage iframes.
Clickjacking and phishing will not occur because the organization is displaying its own facebook page on its own browser-driven display devices.
If the browser doesn't provide an internal x-frame override on its "about:flags" page, you may need to install a browser extension to override x-frame-options on the signage device.