Mixed content warning / can't load http scene files when loading Play under https

[bcamper]

I noticed that since we're often loading Play under https, you can't load a scene file from an http source. Not sure what to do about that since it probably can't be circumvented, but noting it here before I forget. While there's a big effort to move as much of the web to https as possible, it's still not equally or easily available to everyone. Also I don't think we have any user-facing error handling for it right now :)

[louh]

Do you have a test case of a scene file from an http-only source? That is, a URL that will return an error if you attempt to fetch that scene file as https. I want to try something making a protocol-relative request for it, which is a trick that will usually work for other types of resources.

[bcamper]

This might seem like an unusual example (but was something I was trying to do!), loading a local file: http://localhost:8000/demos/scene.yaml

[louh]

Can you try loading that without the protocol? type in just localhost:8000/demos/scene.yaml? and does localhost also support CORS?

[bcamper]

I do see that it uses the current protocol, which will help for cases where the underlying domain can handle https. In my specific example it doesn't work because I'd need to go through some extra hoops to setup SSL locally (can be done, just not done right now).

I don't think this underlying issue can be "solved", but we can make the error handling more appropriate so people know why their file is failing to load.

[bcamper]

While I also generally support moving to https, it is worth discussing if this is the right move for loading the main Tangram Play app. Specific actions can always be done with https where needed for security.

[louh]

Perhaps a proxy for http:// URLs?

Although, this is not necessarily going to help with http://localhost/ urls. Then again, we'd perhaps assumed that opening a scene file from the file system through the browser's open dialog, or drag-dropping them into the browser is how you would load up local files. This was also before the import keyword, though. Would you need to, or expect to be able to use http://localhost/ in either the import or sources sections?

On Apr 25 2016, at 7:52 am, Brett Camper <notifications@github.com> wrote:

While I also generally support moving to https, it is worth discussing if this is the right move for loading the main Tangram Play app. Specific actions can always be done with https where needed for security.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[bcamper]

I think we may want to consider some kind of proxy also for CORS (which really hinders the use of external images), such as using crossorigin.me or running our own version of it.

But while I do use localhost for a variety of things (import, sources, etc.) it's a narrow use case that is mostly about my development flow, not something that I think is important to support for general users right now.

For this issue, I'd mostly just like to see better error handling / messaging in Play so people know when they run into this limitation (rather than inexplicable failure).

[louh]

Generally, any client side script will be unable to differentiate whether a request has failed due to an insecure response, a lack of CORS headers, or any other forms of network failure, so any error handling or messaging we can implement will be quite broad. See here:

http://stackoverflow.com/questions/31058764/determine-if-ajax-call-failed-due-to-insecure-response-or-connection-refused http://stackoverflow.com/questions/19325314/how-to-detect-cross-origin-cors-error-vs-other-types-of-errors-for-xmlhttpreq

In other words, Play cannot be user-friendly about the cause of the problem, although we could have a series of "troubleshooting steps." It would also be much easier to be user-friendly if we could also rely on a back-end proxy for requests.

As for HTTPS, I don't think this is something that's useful to reverse. The mood in the air seems to be that ultimately HTTPS for everything on the web is the right, secure, and privacy-minded move to make. Speaking of which: users of the HTTPS Everywhere extension will never be able to force an HTTP version of Tangram Play, unless we go against the grain and explicitly disable HTTPS for it completely. And finally, we are starting to see many new (more powerful) browser features become HTTPS-only, including the Geolocation API, no longer supported under HTTP in Chrome 50 -- I've recently had to update the permissions detection on Play's "Locate Me" button to take this into account (and in this particular case we can fall back to GeoIP anyway).

For local development, I've found that the easiest way to enable local CORS is to use Node's http-server module (https://github.com/indexzero/http-server) and run http-server --cors. This module also can run --ssl with your own self-signed certificate file. (For backup, in the event that Chrome treats it as invalid, there is a flag that enables localhost resources to be loaded even if the certificate is bad (chrome://flags/#allow-insecure-localhost)). Since this seems to be useful for us, I'll look into writing down some boilerplate recipe that can help with localhost sources with minimal effort.

[bcamper]

Yep, I'm aware of the client limitations in knowing why the network request failed (this is especially problematic for cases where it's a CORS issue, since it's not as well understood by many users). My thinking was simply for Play to examine the URL it is requesting and warn on http requests from https, since it should be able to know this in advance.