HTTPS Availability of Blue Marble and Landsat Imagery

[gbchriste]

High David. Gary Christenot here from the WorldWind TEM. It was great getting to meet you and the rest of the World Wind team. The TEM provided me with some great insights and ideas on where to take our World Wind project next. Based on our experience at Eglin I want to take a very deep dive look at Web World Wind.

I had some time Thursday night after the conclusion of the conference as well as several hours in the airport to do some exploration of Web World Wind as a self-hosted site. I set up IIS on my laptop, pulled in all of the files as local resources, including the Bootstrap, jquery, requireJS libraries, and changed the script references in the BasicExample accordingly. IE still seems to be a bit of an issue for me but successfully got FireFox and Chrome going as a local Web World Wind implementation. By monitoring network traffic I was able to verify that the only external calls going outside of my local web server were the pulls from NASA and Bing servers for the actual globe/map data. So that was a good start.

Where I hit a bit of a road block was trying to implement all of this over https, which is an iron clad requirement for any web application we host. I created a self-signed certificate and loaded it against my site to see how it would behave. The basic skeleton of the BasicExample loaded just fine, as did the Bing data. But NASA Blue Marble and Landsat imagery wouldn't load.

When I traced the network traffic, I could see that Blue Marble data was trying to load from https://worldwind25.arc.nasa.gov/wms and was not getting any response. Digging deeper in to the code I found in the BMNGLayer.js source that it is using location.protocol to set the protocol of the URL to the same as the site. To overcome my immediate issue I changed the code in BMNGLayer.js to hard wire it to "http" instead of location.protocol. That allowed the Blue Marble and Landsat imagery to load in to my World Window, but with a security complaint from the browser about mixed http/https content that had to be acknowledged.

It would seem that based on your use of location.protocol to build the imagery URL that access via either HTTP or HTTPS was to be expected. Is there something I'm missing?

In order to go forward I will definitely need to have access to an imagery source that is accessible over HTTPS, whether that is something NASA provides, I have to self-host, or perhaps can hook on to at NGA or other U.S. Government agency. While the integrity of NASA servers is obviously not in doubt, I can't guarantee that our user's would have the option of acknowledging and accepting warnings on mixed HTTP/HTTPS traffic in the browser. I have elevated privileges but most of our users would probably have their browsers locked down to not be able to accept that warning. And if they aren't locked down now, they very well could be in the future.

If NASA imagery isn't available over HTTPS, do you know if, as a U.S. Government agency, there are NGA or other U.S. Government mapping servers I might point to that would be HTTPS?

I'll reserve the idea of hosting data on an internal HTTPS resource as a last resort. I mentioned to you that I have the Blue Marble and Landsat data in the older DDS format being served up from a local instance of World Wind WMS server that was included in v1.5 and earlier. Technically I shouldn't be hosting that on my application server since it is an HTTP resource. But because all users are on my internal network it has been allowed to slide thus far. But you mentioned there was a way I could use that data. If I have to come back to the idea of hosting my own HTTPS imagery source, perhaps we could revisit that in a later conversation.

Looking forward to working with you guys going forward!

Gary

[pdavidc]

Hi Gary, Supporting Web World Wind apps deployed via HTTPS is a high priority for the NASA World Wind team. The key issue is installing HTTPS certificates on NASA imagery and elevation servers, which we're working on now. You'll see individual GitHub issues related to HTTPS as we make progress toward that goal.

[gbchriste]

Great news! Thanks David. Looking forward to continued cooperation with the Web World Wind team.

Gary On Sep 8, 2016 6:09 PM, "David Collins" notifications@github.com wrote:

Hi Gary, Supporting Web World Wind apps deployed via HTTPS is a high priority for the NASA World Wind team. The key issue is installing HTTPS certificates on NASA imagery and elevation servers, which we're working on now. You'll see individual GitHub issues related to HTTPS as we make progress toward that goal.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NASAWorldWind/WebWorldWind/issues/44#issuecomment-245770254, or mute the thread https://github.com/notifications/unsubscribe-auth/AUDI-QEtykq9fBerGhr5ICwaYHTXUTRwks5qoJW6gaJpZM4Jj6PN .

[pdavidc]

The map services hosted by NASA have been updated to use the HTTPS protocol. We're migrating the World Wind client code now. Since the migration involves the broader set of map services provided by NASA, we're capturing our progress in an independent issue, #66.

[pdavidc]

Closed per #66.