Note: This blog covers the classic Esri Story Maps. Story authors are encouraged to use the new ArcGIS StoryMaps to create stories; however, Esri will continue to maintain the classic templates for your use. For more information, see the Product road map.
Attention Story Map Authors:
Please read this important message as it may require you to take action and change how you build story maps.
When you make a story map, you expect it to work and that your audience will be able to use it for a long time after you publish it. But story maps are web apps that readers access using a web browser, so your stories are subject to the different and evolving security features of each browser. Sometimes the mission of web browsers to keep users and their information safe can affect your readers’ ability to access and enjoy your story map as you intended.
The purpose of this post is to let you know we are working to help minimize the negative impacts of these situations and that there are things you may need to do to ensure your stories continue to work as browsers implement new, more stringent security features.
What is Esri doing?
To help you build stories that work with web security standards now and in the future, the Story Maps Team has a plan to migrate all our apps to require HTTPS for both building and viewing stories. This means a story map app and all content (images, videos, map layers, web pages and apps) loaded within it must be accessed using HTTPS URLs. We want this transition to be as smooth as possible, but some of the planned changes have the potential to break stories you have already published, so we want to make you aware of the plan to provide plenty of time to address any issues.
We’ll begin to roll out incremental changes to our apps
later this year in 2018 that will help you make the transition. In the first phase, story map apps will begin to require you to provide HTTPS links for embedded content, and we’ll provide tools to scan your stories for HTTP links.
We plan for all story map apps to require HTTPS in
the first half of 2018. At that time, we will have story map apps automatically switch any remaining HTTP content links to HTTPS. While this will alleviate issues in many situations, it’s unfortunately not that easy. If the content embedded in your story is hosted on a server that doesn’t support HTTPS, the story will break. We recommend you follow the instructions in this blog and take advantage of the tools that are forthcoming to check your stories and address any issues before this change is implemented.
This issue affects all authors and users of story maps and is independent of whether your administrator currently requires traffic to your ArcGIS Online organization to be over HTTPS.
What do you need to do?
The two main things you need to do are:
- Always use HTTPS links for content that you add to a story map, including images, videos, layers, and embedded apps and web pages.
- Review your existing story maps to identify any embedded content that uses HTTP links and update those links to HTTPS.
If any embedded content in your existing stories does not work after the link is changed to HTTPS you can either:
- Update the server to support HTTPS
- Move the content to a different server that supports HTTPS and update the link in your story
- Add a link in your story narrative that opens the content in a new browser tab (rather than embedding it in the story)
- Find replacement content that supports HTTPS
- Remove the content from your story
Following these steps will ensure your new and existing stories will continue to work well for your readers. If you need help understanding why a server doesn’t seem to support HTTPS or how you can host content on a secure server, check with your IT department.
To summarize, we’d recommend that you:
1) immediately adopt the practice of using HTTPS links for embedded content in new stories, and
2) begin the process of reviewing your existing stories to find and address HTTP links now.
That’s the crux of the matter, but we encourage you to read on for more information about these changes and how to address them…
What are http and https anyway?
They are protocols that define how information is sent between your computer and other computers on the web. HTTPS is a secure communications protocol, which means it’s encrypted and protects the information you are sending and receiving so that only the intended recipient can read it. There’s a lot more information about it on Wikipedia, if you are interested.
What should you do when creating new stories?
If you’ve uploaded images in a story map builder or used images stored as items on arcgis.com you have nothing to worry about. For any new stories you create, uploading images in the story map builder is recommended as the easiest, best, and most secure way to add images to your stories.
If you need to use images that are hosted somewhere else on the web, then use HTTPS URLs when adding images to new story maps you create. This includes pasting a link to a logo for your story map header or adding an image anywhere in the body of your story.
Also use HTTPS URLs when adding any content that will be loaded inside your story map. This includes <iframe> code for a dynamic chart from a third-party service, a URL to an audio file, or service URLs for GIS server layers in maps or scenes.
What about stories you’ve already published?
Go back through any story maps you have shared with the public and look for any HTTP URLs pointing to images, videos, map layers, web apps, or web pages. You can safely ignore HTTP links for content hosted on arcgis.com. You can also ignore content that you have hyperlinked to; for example, if you created a text hyperlink to a PDF report that opens in a new browser tab that link can be HTTP or HTTPS. You only need to be concerned with content that is loaded inside your story map that is hosted outside the arcgis.com domain.
If you find content with an HTTP link that is hosted outside of arcgis.com you’ll need to either update the server with a valid certificate so that it will support HTTPS or find an alternate way to host the content securely.
If the content is an image you can upload it in the story map builder or host it on a different web server that does support HTTPS. If the content is a GIS service the recommended path is to update the server to support HTTPS. If that is not feasible you can publish the data to ArcGIS Online or to a server that does support HTTPS. If you do republish the data somewhere else you’ll need to update the URLs in all web maps that use that layer.
When updating an existing server to support HTTPS the URL to your content may change (for example, if the port number is included in the URL). In these cases you’ll need to update the URLs in your story.
Can you give me examples of how a browser’s web security features can affect a story map?
In some cases the problem is obvious, such as when the content embedded in your story map doesn’t even load. See this blog for information about these types of situations and how to troubleshoot them. In other cases, however, the affects are more subtle.
For example, Safari recently began blocking the use of its geolocation feature if any content — even a single image — is loaded over an non-secure (HTTP) connection. Geolocation is blocked even if the web page itself is loaded over a secure (HTTPS) connection. Let’s say you created a story using the Story Map Tour app. When you were adding your organization’s logo to the header you pasted in an HTTP link to the logo image. This means that anyone trying to use to your story over HTTPS using an iPhone or iPad won’t be able to tap the “locate me” button to locate themselves on the map. While your app will still work in this case, it’s not providing the intended experience for your readers.
Web browsers are constantly implementing new security features like this to keep users safe. The issue mentioned in this example may only affect Safari users today, but soon other browsers are likely to implement this safety measure as well.
If you have questions about this issue or how it may affect you, please post them on GeoNet.
This blog was originally published in June 2017 and was updated in December 2017.