Loading JS flot external resources using JSFiddle - resources

I'm trying to create a JSFiddle loading external resources (Flot). However, when I add my external resource:
http://www.flotcharts.org/flot/jquery.flot.js
I get this alert error in JSFiddle
You're loading resources over HTTP not HTTPS, your fiddle will not work. Do you wish to continue?
However, the https version of flot,
https://www.flotcharts.org/flot/jquery.flot.js
has security warnings associated with it (in Chrome, the error is listed as "Your connection is not private"). What is the proper way to extenrally load flot into a JSFiddle?

When you're creating a fiddle, JSFiddle requests HTTPS content but it does not need it.
Create your fiddle using https://jsfiddle.net (Click ok on the warnings when adding your http:// external resources) and click save.
Once you click save, you'll be redirected to your JSFiddle saved URL. On this URL, just change https:// to http:// and it will work.
Example here http://jsfiddle.net/kL1wuh66/1/

Related

CSP issue with iframe loaded from chrome extension

I'm developing a chrome extension that renders and sidebar iframe in Gmail.
A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as
Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...
To fix it, we had to rewrite the CSP header as explained in this blog post.
However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.
As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.
Notes and attempts:
Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.
We've tried to remove and re-add the extension but that didn't yield any permanent results.
Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.
[Update]
It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.
More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.
I can provide snippets and more info if needed.

How would I force my page to be loaded *only* in an iframe

I want to host a webpage that can only be served via iframes within my own domain.
An example of this in the wild would be Codepen. They sandbox the content of a "pen" in an iframe, but if you try to load the url from a browser it responds with an empty page.
I understand there might be multiple answers to this question but I'm hoping someone could point me in the right direction.
Would I be checking the referrer server side? Are there any other options?
Referer is a good start for the server side.
Also you can try using CORS headers:
Only allow iframe to load content
Or validating using client side javascript code:
How to identify if a webpage is being loaded inside an iframe or directly into the browser window?
Also check info about referrerpolicy
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-referrerpolicy

Website HTTPS certificate

Since I've been adding an ssl certificate today and everything worked out good i'm still facing one problem.
i'm having insecure http which makes the green bar on top of the page go away. I want all my content on my website to load from https.
<img href="http://...."></img>
Needs to go to a https link for my images. I know I could manually adjust them all but I'm using plugins which load their own content from http links. I tried .htaccess files and i am also using them to force https on my website. But img tags don't see to change their href link to https.
I know i could manually adjust them all but i'm using plugins which
load their own content from http links.
If you already know the above restriction, the the following requirement would never be satisfied.
I'm having insecure http which makes the green bar on top of the page
go away.
The green bar is there because everything is being served over HTTPS, including your own calls, third-party plugins, any hidden frames/scripts/stylesheets etc.
You'll need to manually update your src="http:// (img tag uses src or srcset attribute and not href) links to point to https URLs. Even if your htaccess is set to forward HTTP calls to HTTPS, the browser sees an HTTP link, and turns your green bar to yellow (or red)!

Joomla wrapper and ssl

I have joomla site and i set ssl on it. In some pages i have wrapper that load some form from another server.
When i used http it worked normal but after https it load too long and at the end show times out.
If i don not write any protocol in url and set
Add protocol - Yes
that time page loading normal but form blocks by browser.
link to page
What need to do load wrapper normal or how to exclude page from ssl
You are calling http content inside your web. This is the console output:
Mixed Content: The page at 'https://carzilla.az/ru/voditelyu/proverka-shtrafov' was loaded over HTTPS, but requested an insecure resource 'http://85.132.44.29/nex'. This request has been blocked; the content must be served over HTTPS.
Try changing http://85.132.44.29/nex to https://85.132.44.29/nex
Is maybe that your problem? This resource is blocked.
EDIT
Anyway, when calling the https URL, has no service.. then I think you will not be able to open that URL in a HTTPS situation.
This is not a programming question, it is a site administration question.
WHen you make the wrapper menu link, simply go to the metadata tab and tell it to make the link "not secure."

Why is Chrome reporting a secure / non secure warning when no other browsers aren't?

When I go to our web site through HTTPS mode, Chome is reporting an error saying that the page contains secure and not secure items. However, I used Firebug, Fiddler, and HttpDebuggerPro, all which are telling me that everything is going through HTTPS. Is this a bug in Chrome?
Sorry but I'm unable to give out the actual URL.
A bit late to the party here but I've been having issues recently and once I had found a http resource and changed it was still getting the red padlock symbol. When I closed the tab and opened a new one it changed to a green padlock so I guess Chrome caches this information for the lifetime of the tab
Current versions of Chrome will show the mixed content's URL in the error console. Hit CTRL+Shift+J and you'll see text like:
"The page at https://www.fiddler2.com/test/securepageinsecureimage.htm contains insecure content from http://www.fiddler2.com/Eric/images/me.jpg."
I was having the same issue: Chromium showing the non-secure static files, but when everything was http://.
Just closing the current tab and re-opening the page in another new tab worked, so I think this is a Chromium/Chrome bug.
Cheers,
Diogo
Using Chrome, if you open up the Developer Tools (View > Developer > Developer Tools) and bring up the Console and choose to filter to warnings, you'll see a list of offending URLs.
You'll see something like the following if you do have insecure content
The page at https://mysite/ displayed insecure content from http://insecureurl.
For the best experience in finding the culprit, you'll want to start your investigation in a new tab.
It is possible that a non-secure URL is referenced but not accessed (e.g. the codebase for a Flash <object>).
I ran into this problem when Jquery was being executing a a few seconds after page load which added a class containing a non-secure image background. Chrome must continually to check for any non-secure resources to be loaded.
See the code example below. If you had code like this, the green padlock is shown in Chrome for about 5 seconds until the deferred class is applied to the div.
setTimeout(function() {
$("#some-div").addClass("deferred")
}, 5000);
.deferred
{
background: url(http://not-secure.com/not-secure.jpg"
}
Check the source of the page for any external objects (scripts, stylesheets, images, objects) linked using http://... rather than https://... or a relative path. Change the links to use relative paths, or absolute paths without protocol, i.e. href="/path/to/file".
If all that if fine, it could be something included from Javascript. For example, the Google Analytics code uses document.write to add a new script to the page, but it has code to check for HTTPS in case the calling page is secure:
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
On the release of Chrome version 53 on Windows, Google has changed the trust indications to initiate the circle-i. Afterward, Google has announced a new warning message will be issued when a website is not using HTTPS.
From 2017 January Start, Popular web browser Chrome will begin
labeling HTTP sites as “Not Secure” [Which transmit passwords / ask
for credit card details]
If all your resources are indeed secure, then it is a bug. http://code.google.com/p/chromium/issues/detail?id=72015 . Luckily it was fixed.

Resources