I have an iFrame (https://example.com/iframe) that runs within http and https protocols (ie. http://example.com and https://example.com/login).
This iFrame has a conditional that sometimes forces a page refresh
window.top.location.reload();
When on https://example.com/login the reload works fine. When on http://example.com the reload doesn't work (as expected due to same origin). This is OK. The iFrame is doing other background activities that are good for the user experience in both instances.
This is the error that Chrome gives, I am sure others do the same:
Unsafe JavaScript attempt to access frame with URL http://example.com
from frame with URL https://example.com/iframe. The frame requesting
access has a protocol of 'https', the frame being accessed has a
protocol of 'http'. Protocols must match.
MY QUESTION: Is it Ok to have this error? It doesn't bother me, but will it impact the user experience, stop certain browser activities, etc?
This doesn't effect the functionality of page. You are seeing this error because your main page is from https:// and iframe you are loading in that page is from http://, That is the only reason. Try using relative protocol e.g.; <iframe src="//example.com"/> and try to correct this warning. It is ok to have this error but this error should be solved because this may impact user experience in few circumstances depending your page code approach.
Related
Click Me
This used to work as a valid href attribute but it seems in the past few months it now shows an error in the console (I'm using Chrome):
Not allowed to load local resource: view-source: http://stackoverflow.com
I found some links from 2013 where this was once a bug in Chrome but said it was fixed.
Could someone point me to an authoritative source that can explain why this no longer works? I assume that this is security by the browser and not an angular issue (since view-source is whitelisted and used to work)
Looks like Chrome and Firefox (at least) disabled this within the past year or so
I found this thread, and these release notes explaining why and provides a timeline as to when the change took place.
Related StackOverflow question: File URL "Not allowed to load local resource" in the Internet Browser
Chrome responds with the "Not allowed to load local resource:" as a security protocol. I'm not sure why this used to work, but not now, though there is no real way around this unless web-security is disabled. There may be a different outcome on other browsers, but ultimately you are correct in thinking that it's Chrome's security.
The reason is that Chrome tries to preload URLs in background, to speed up your browsing experience.
If you open the DevTools after loading the page, the content of the items listed on the Resources tab may not be populated. This is also true of network requests on the Network tab. To see the fully populated resources on the Resources tab, first open the DevTools, then refresh the page, or navigate to the desired page with the DevTools open. Now select the html resource and it should be populated.
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
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.
my problem is that I am using the canvas .toDataURL() method to display a preview of an image on Chrome and Firefox but that is causing a warning to appear because the site is over a SSL connection.
I get the following warning message when I display the image using toDataURL():
The page at ... displayed insecure content from ....
This only happens in Chrome since chrome has that Lock next to secure web pages:
Which causes the Green Lock on the address bar to change state to a warning state saying that there are resources on this page that are not secure.
Is this an expected behavior for toDataURL()?
I don't see why it would be unsecure since I am not fetching any data over an HTTP connection or even fetching any data at all since it is all done via JavaScript.
But I am probably wrong, please correct me.
Is there a different way for me to make sure I am securing this content? Or to not cause the warning to occur? (And I do need to use the .toDataURL() method?)
Open the Developer Tools console in each browser and look for the exact URL that they're claiming is insecure. It would be very surprising to learn that either browser has such a bug. IE7 and below have this bug, but they don't support DATA URLs at all.
If you're displaying the image from an unsecure location (file://) you can't move it to a secure context (https://) without running into errors. This might be causing the browser to treat it as insecure.
Recommended reading:
SECURITY_ERR: DOM Exception 18 on using getImageData in a Chrome Extension
HTML5 Canvas - How does the origin-clean flag get set to false?
Visiting my site in SSL and in Chrome (12.0) I get
Your connection to someWebsite is
encrypted with 256-bit encryption.
However, this page includes other
resources which are not secure. These
resources can be viewed by others
while in transit, and can be modified
by an attacker to change the behaviour
of the page.
The connection uses TLS 1.0.
The connection is encrypted using
AES-256_CBC, with SHA1 for message
authentication and DHE_RSA as the key
exchange mechanism.
The connection is compressed with
DEFLATE.
I searched with FireBug (NET tab) and Chrome Inspector and all resources are accessed via https. Where is the problem? *I cleared the cache already
What could be the problem?
Chrome will give this error if you've visited another https page on the same domain that had mixed content however this should not be the problem if you've tried clearing your cache.
You might want to try Ctrl-Shift-J for the JavaScript console, it should show the insecure content.
I have the same thing - and I read from the Google Chrome help site that elements on the site are not encrypted - like videos. I looked via Firefox - right click->View Page Info->Media tab and saw that every time I use a YouTube video in my video player I have plain http addresses like:
http://s.ytimg.com/yt/swfbin/watch_as3-vflrEm9Nq.swf and
http://img.youtube.com/vi/V6JgyNy59yA/1.jpg
I think these non https links are causing the security message site-wide. Thus, it appears using videos from 3rd party sites will always throw a security error in Google Chrome for https pages.
That's my answer - but I have no solution yet. I need to be able to share videos from youTube in our news section, but my online store section needs to use https without scary red letters and slashes through it for my clients.
Has anyone dealt with this effectively?
Thanks
Had the same problem on my Magento Site. Be sure to change all image and js links (even in .css) from http:// to simply //. Solved it for me.
I had the same issue, my problem was that some img tags had src to http instead of https, it does not matter even they link to other domain like <img src="http://otherdomain.com/image.jpg" /> it still shows that warning. As soon as I changed all internal and external img links to https the warning disappeared.
If you check the page and it seems to have no insecure content, check to make sure that something on the page is not submitting data to an insecure location.
Content should be submitted over HTTPS, not HTTP.