I have a site with HTTPS configured.
My client wants me to embed a youku video. At first the browser blocked the iframe since it had HTTP protocol on it.
I changed it to HTTPS and now youku does not work. It seems youku does not support HTTPS.
is there any way around this?
Perhaps there is a service other than youku that does support HTTPS and is still suitable for that region?
hi，we had supported（sorry for later）
for example:
1
<iframe height=498 width=510 src='https://player.youku.com/embed/XMTg3Nzg4MzY4NA==' frameborder=0 'allowfullscreen'></iframe>
2
https://player.youku.com/player.php/sid/XMTg3Nzg4MzY4NA==/v.swf
3:
<embed src='https://player.youku.com/player.php/sid/XMTg3Nzg4MzY4NA==/v.swf allowFullScreen='true' quality='high' width='480' height='400' align='middle' allowScriptAccess='always' type='application/x-shockwave-flash'></embed>
Youku player serves some resources (like preview images or alternative sources for video) under http, not https - and this might be the main culprit of "partially insecure content" issue in browsers. This problem is caused by Youku player itself, it's quite possible to change the code loaded from their servers.
However, the problem can be solved in most simple and convenient way by rewriting insecure http requests on given page with secure https requests - it possible to achieve this by including CSP meta tag in page header:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
The "Content-Security-Policy" response header allows to control resources the user agent is allowed to load on given page (more information here).
What "upgrade-insecure-requests" directive does: "Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten."
The original solution was found in this post.
Related
I've got a site where I recently started using SSL and now in console I'm getting a couple of errors;
Mixed Content: The page at 'https://www.XXXXX.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://fonts.googleapis.com/css?family=Droid+Serif'. This request has been blocked; the content must be served over HTTPS.
I've read that I could specify the stylesheet as: //fonts.googleapis.com/css?family=Droid+Serif and omit the http:// or https:// and let the browser determine which scheme/protocol to use, but I'm surprised I've not seen this before and wondering if this is good practice?
For example, in my Wordpress theme development where I am frequently using wp_enqueue_style should I now use this format by default, assuming where you're calling from is able to serve both?
I'm considering just redirecting all traffic to the https version of the site, but still interested to know if this URL scheme is good practice or not?
We have a HTTPS website and I need to display a HTTP website (any external website) into my page. The website used iframe for displaying it. We realised that it doesn't work in mozilla firefox. We are getting a "mixed content" error. I am searching for an alternative to iframe now. I understand that it makes no sense to bypass the security warning. We also do not want to change any browser settings as it is possible that all the users may not have permissions to change browser settings. Using tags like <embed> or redirecting in <div> tag also gives the same problem.
Is there any way to do this in C# code and not using HTML and scripting.
Response.redirect() does not work in our application. I do not have a problem if the page is redirected but I prefer a dialog/popup window for the external website to display.
This is simply a security consideration. Your HTTPS site is not truly safe when using mixed content.
Use HTTPS for your external site, period.
As Mozilla suggests:
The best strategy to avoid mixed content blocking is to serve all the content as HTTPS instead of HTTP.
I have a https site and need to show content from other sites that may or may not be themselves https. Predictably enough, I'm getting warning messages like this in the console...
"Mixed Content: The page at 'https://www.example.com/' (my server) was loaded over HTTPS, but requested an insecure image 'http://www.aninsecuredomain.com/image.jpg'. (not my server) This content should also be served over HTTPS."
(not to the mention the fact that I no longer see the little padlock displayed properly in most browsers who now consider my site's network insecure).
I've read through a bunch of posts on SO on this topic, but I can't seem to find a definitive answer on whether there's anything I can do when I don't own the external servers (so can't guarantee they'll have a https version). Appreciate any thoughts on whether this is possible, and if so how I could go about achieving it!
When you need to include content from another domain in an https webpages you can:
Make the owner of the other domain commit to https by explaining him the security reason behind that
Proxy the content through your website or host it yourself (if you have right to do it)
(If you don't see the padlock anymore it's because your page is no longer secure because it include insecure elements that could have been tempered: it's not they "consider my site's network insecure", it is indeed insecure!)
You should use the // prefix. (instead of http[s]://)
On an https page, the secure version wil be loaded.
On on a plain http page, the plain http version will be loaded.
Edit your theme replacing every occurence of http://fonts.googleapis.com/... with //fonts.googleapis.com/...
Using IIS6 on win2003, if I have an image server is it more efficient to serve up images as http than https? Also is it possible to serve up images as http on a webpage than is https.
Like if this html file: Secure.html is on a server that forces https to be used, but inside https://www.myultrahighsecurewebsite.com/Secure.html/
and I have a image like so:
<img src="http://www.notsosecureatall.com/imagecode/serveupanimage.aspx?id=1&auth=1" />
Is this a good way to serve up images? Is there a better way? Also I wanted to have a defacto site to serve up images so I don't have to push images as well as code and markup between development and live. Should the images or certain type of images like tiff, png, svg, etc... be on https vs http or does it matter?
If I do implement an image server or a page dedicated to keeping track of images, I just want an easy system to push images from development to my production environment without getting snagged on installation problems. But also not having to worry about customers having access to images until a version has been properly approved.
It will be more efficient from a CPU (client & server) and network point of view to use plain old HTTP. You'll avoid the overhead of TLS traffic and encryption/decryption of data.
The scenario (mixed HTTP/HTTPS) you present will often annoy a user though. You'll get a warning similar to "This page has unsecured content" (this is getting at the HTTP-only images).
See Loading http content on https website for more info (and additional gotchas) on the previous paragraph.
Are you sure that you need to worry about efficient loading of images? Don't overengineer this. Please share some more details if you've noticed that this is a problem.
My server deliver page via HTTPS (as well as any resource on the page). The page by itself comes from main domain: domain.com, while other resources such as images or css comes from the following subdomains:
img.domain.com and css.domain.com respectively. Images and css resources have Cache-Control in response headers, i.e. they should be cached.
The question is why the browser requests images and css resources each time I open the page?
On other hand, if all resources comes from the same domain - everything is taken from the cache? Why it is so? And it looks like this behavior is not the same in different browsers: in some browsers I see conditional requests while in others - unconditional. Is there any standard for such case?
Is Cache-Control set to public for the resources from the alternative domains?
This is a bit of an ancient (2009) article that might help - http://blog.httpwatch.com/2009/01/15/https-performance-tuning/
I'd also consider whether you want to serve the CSS from a separate host...
the browsers going to have to do a DNS lookup, and open up a new TCP connection
if you used the same host DNS lookup goes away, connection overhead may go away (IE9, Chrome speculatively open a second connection), but you get the overhead of the HTTPS negotiation back.
I don't know the right answer without measuring but it's worth thinking about.