Our iOS application uses a custom protocol (NSURLProtocol) to directly manage loading certain data needed by a UIWebview. This has worked fine until iOS 9 with XCode 7.
Now, since the main site is loaded using HTTPS, the UIWebview throws an error when the custom protocol resource is referenced, because it thinks it's insecure (in fact, it's not, we load it using SSL, just not https://). The app is already built with "Allow Arbitrary Loads" because we have some other things that require that, and I would have thought this inherited the NSTemporaryThirdPartyExceptionAllowsInsecureHTTPLoads, which it seems this is hitting up against, but who knows.
Is there any way to convince iOS 9 that our custom protocol can be accessed from HTTPS? Note - we don't use an iframe or anything like that in the UIWebview - these resources are requested using Ajax/XHR and the app's NSURLProtocol is invoked and takes over loading the data and returning the response.
The custom scheme is also listed in URL Types, but this doesn't seem to change any behavior (in or out, same error). Here's the specific error:
[blocked] The page at https://example.com/path/redacted was not allowed to display insecure content from mycustomprotocol://different.example.com/path/redacted.
EDIT: Downloaded Xcode 6.4, rebuilt the app and it seems to work just fine on iOS 9.x, no issues with the custom protocol. Obviously, this isn't a long-term solution. Hoping someone still has some insight on how to resolve in Xcode 7+.
The problem, I suspect, is that web pages served by https aren't generally allowed to include resources loaded from any URL whose scheme isn't on a specific list of known-secure schemes (at least in newer browsers).
The best way to work around the problem is to rewrite your resource URLs to begin with https: and make them all be within a specific subdomain that you own, and permanently ban any actual web use of that subdomain, then use that to determine whether your URL protocol should handle the URL, rather than using the URL scheme.
With that said, please file a bug and ask for an API to whitelist your custom protocols as "potentially secure" in UIWebView and WKWebView. In this case, it is a reasonable thing to do.
For more info on mixed content, see http://www.w3.org/TR/mixed-content/
Related
Sometimes, if I go to a website, such as this one through an HTTP link, it looks fine and works as apparently intended:
However, if you change the address to be HTTPS, the page loads without any browser warnings but looks really weird and seems broken—spacing is messed up, the colors are wrong, fonts don't load, etc.:
All of this same stuff happens in both Firefox and Chrome on my computer.
What causes this to happen? How can I avoid this if I make an HTTPS-secured website?
For me the browser tells you what is wrong in a warning message. Parts of the page are not secure (such as images).
What does this mean? The developer of the site has linked some content such as CSS, JS, or images using HTTPS links and some using HTTP links.
Why is this a problem? Since some content is being retrieved over an insecure connection (http), it would be possible for malicious content to be injected into your browser which could then grab information which was transmitted over https. Browsers have had this warning for a very long time, but in the interest of security they have hedged their behavior on the more secure side of things now.
What will fix this? There is nothing we can do as consumers of the website. The owner of the site should fix the problem. If you are really interested in viewing the site and not concerned about security, you can temporarily disable this protection from the URL bar warning message in Firefox.
As #micker explained, the page looks weird because not all of the sources are loading since their connections could not be made securely and the website's ability to load those sources are being denied by the browser for not being referenced using a secure connection.
To elaborate further. in case it's still not quite clear, a more accurate and technical explanation would be that, for styling a webpage, the Cascading Style Sheets, or CSS, is the language used to describe the presentation of a document or webpage in this case, and tells the browser how elements should be rendered on the screen. If you consider these stylesheets as sort of building blocks, where you can combine them together to define different areas on a webpage to build one masterpiece, then you would see why having multiple building blocks for a site would sound pretty normal.
To save even more time, rather than try to figure out the code for each and every stylesheet or "building block" that I want to include, I can burrow someone else's style sheet that has the properties I want and link to it as a resource instead of making or hosting the resource myself. Now if we pretend that there's a stylesheet for every font size change, font color variance, or font placement, then that means we're going to need a building block to define each of those
Now, If I am on a secure connection, then the browser ensures that connection stays secure by only connecting to other sites, or resources, which are also secure. If any of the sites containing the building blocks of CSS that I want to use but are not secure, AKA not using SSL (indicated by a lack of "s" in "http://" in their address), then the browser will prevent those connections from happening and thus prevents the resources from loading, because the browser considers it a risk to your current secure connection.
In your example's particular case, things looked fine when you entered only http:// without the https:// because the site you were visiting doesn't automatically force visitors to use SSL and lets you connect to it using the less secure, http protocol, which means your browser is not connecting securely to it, and therefore won't take extra steps to protect you by blocking anything outside of that since you're already on an insecure connection anyway. In which case, the browser doesn't need to prevent sources that are coming from an insecure connection or sites because in a way, your connection is already exposed so it can freely connect where it needs to and load any resources regardless if they can be transferred securely or not.
So then, when you go to the "https://" version of the site, there are no browser warnings because you're connecting to that site with a secure connection and unfortunately that also means that if the designer of the page had linked resources from somewhere that just didn't have an SSL connection available or didn't update the link to go to the new https:// standard, then it's going to be considered insecure and since you're on a secure connection, the browser will block those connections which means blocks those resources from being able to load, making the page load incomplete with not all of its building blocks. Build blocks that tells your screen to move all the text on the right into a panel and to have a blue font color while changing to a different font face. Those definitions defining the look and appearance didn't make it through and so those sections adopted whatever existing stylesheet is present which normally don't match with what was intended to be there.
I have a lot of experience with YUI2 and I'm getting up to speed on YUI3. The service I'm writing needs HTTPS, but the vanilla YUI experience loads from Yahoo's HTTP-only CDN, which quietly fails in Chrome and loudly fails in modern IE when the browser tries to mix an HTTPS page with HTTP javascript.
My goals are to get all of:
Site uses HTTPS
YUI works in Chrome & IE (so scripts also must be delivered over SSL)
Uses a modern version of YUI 3 (this disqualifies YUI PHP Loader which hasn't been updated to support even YUI 3.4, while 3.8 is "current")
Use roll up combos for speed instead of many JS and CSS files (this disqualifies Google's CDN... if YUI 3 is actually hosted there which I couldn't find.)
Site dynamically loads YUI dependencies (dependencies change regularly as I add functionality, going back to the configurator and saving a new bundle every time is a PITA)
The obvious solution appears to be to give up goal #5 and just self-host combos.
How can I meet all 5 goals?
The easiest way to solve it is to change base URL from
http://yui.yahooapis.com/ to
https://yui-s.yahooapis.com/
Depending upon your server environment, you have a couple of options.
Development
Download the latest YUI library, and upload the yui/build/ folder to your server. The seed file should work fine without modification, though you won't be able to take advantage of combo loading.
Production
Use the YUI Configurator to determine all the files that you will need for each module set, and download them manually from the combo links provided. Rename them to something suitable like yui3.8.0-node-rollup.js and serve these to your users.
Be advised that if you use different module sets for different scripts, you may need to make multiple sets of files from this process, depending upon how you set it up. There is also a question here about concatenating Javascript together, if you are curious.
As an addendum, in my past research, I discovered that pulling external libraries over a secure connection may not be a safe idea.
I'm trying to copy the mixed content feature of chrome into firefox. What I've got so far is to block all non-https requests on a site that is https. The problem is that navigation is treated the same as resources. Specifically, once on an https website, I can't navigate away from the site because the non-http request to navigate away is being rejected due to my code.
How do I see the difference between navigation and resource requests?
Well, I couldn't find an answer specifically to my question, but through other roots my friend was able to get the same solution. Resources that were useful follow:
https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIContentPolicy
2:40 AM
https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsICategoryManager
2:41 AM
https://developer.mozilla.org/en-US/docs/XUL_School/Intercepting_Page_Loads#Content_Policy
We are grabbing our feed at feedburner by using the jquery jGFeed plugin.
this works great until the moment our users are on a httpS:// page.
When we try to load the feed on that page the user gets the message that there is mixed conteent, protected and unprotected on the page.
A solution would be to load the feed on https, but google doesn't allow that, the certificate isn't working.
$.jGFeed('httpS://feeds.feedburner.com/xxx')
Does anyone know a workaround for this. The way it functions now, we simply cannot server the feed in our pages when on httpS
At this time Feedburner does not offer feeds over SSL (https scheme). The message that you're getting regarding mixed content is by design; in fact, any and all content that is not being loaded from a secured connection will trigger that message, so making sure that all content is loaded over SSL is really your only alternative to avoid that popup.
As I mentioned, Feedburner doesn't offer feeds over SSL, so realistically you'll need to look into porting your feed to another service that DOES offer feeds over SSL. Keep in mind what I said above, however, with respect to your feed's content as well. If you have any embedded content that is not delivered via SSL then that content will also trigger the popup that you're trying to avoid.
This comes up from time to time with other services that don't have an SSL cert (Twitter's API is a bit of a mess that way too.) Brian's comment is correct about the nature of the message, so you've got a few options:
If this is on your server, and the core data is on your server too, then you've got end to end SSL capabilities; just point jGFeed to the local RSS feed that FeedBurner's already importing.
Code up a proxy on your server to marshall the call to Feedburner and return the response over SSL.
Find another feed service that supports SSL, and either pass it the original feed or the Feedburner one.
i have started using WordPress paid theme Schema for my several blogs. In general, it is a nice theme, fast and SEO friendly. However, since my blogs are all on HTTPS, then I noticed that if I had a widget of (Google Feedburner) in the sitebar. The chrome will show a security error for any secure page with an insecure form call on the page.
To fix this, it is really simple,
you would just need to change the file widget-subscribe.php located at /wp-content/themes/schema/functions/ and replace all “http://feedburner.google.com” to “https://feedburner.google.com”.
Save the file, and clear the cache, then your browser will show a green padlock.
and i fix this in my this blog www.androidloud.com
is there any open source or free "web based proxy" server project that I can look into? I looking for one that don't required configuring browser sock..etc and having web basad interface. Does squid able to do that?
I used to need that several yeas ago. I don't think any supports SSL:
PHProxy - Supports javascript and cookies, but not AJAX or Flash that loads external content (such as youtube)
PHP-Proxy - I don't remember much about this one, but I remember it not playing well with images.
glype - This is a new one for me, I've never tried it.