Hello All,
I have a tabbed story map that I've created in the Map Series Builder. We had some issues with a server going down, so all of our stuff needed to be re-served. I've fixed all of the rest services URLs, and made sure the maps display correctly. However, when I go to my story map, it says that I have issues that need to be fixed. My layer draws correctly, but in the issues window, the layer is "inaccessible." I've tried to remove the map and re-add it, but there are still issues with the layer. I suspect that something is hidden, but I don't know how to fix the issue! (See the attached screen shot for clarification). To reiterate--the layer is showing on the screen as it should.
HELP!
annina
Solved! Go to Solution.
We decided to check the service URLs by the protocol of the app, instead of by their own protocol (so if the app is over http, we will check services over http, even if the service URL's protocol was https). In your case, this same issue should still happen for other stories when checked over http (as long as they are using services that don't work over http). Checking the story over https should correctly show the layers as working.
I don't see any issues with layers being https -- https services can be accessed from an app that is over http or https. In fact, the converse would be a "mixed content" problem -- if you had your service URLs over http but the app was over https, in many browsers the services would not be able to load for security reasons.
Hope that helps, and thanks for your feedback.
Hi Annina. What is the type of layer that you are seeing this issue with?
Both Feature and Map Image Layers, in multiple applications.
OK. What browser and OS were you using? And was it over http or https?
I've tried the applications in both Chrome and IE, and the issue is in both. I'm running Windows 7 Pro, SP1. The layers are over https.
Got it. I'm not sure what the issue might be. Would you be able to share the link of the story and of one of the services that is showing in error?
Sure. Everything's actually shared with "Everyone." Here is a link to the story map: http://arcg.is/1JT0Qa6
The only layer in the map (besides the basemap, which isn't erroring), is called "Before_After_StoryMap." You can search for this on ArcGIS Online, and it's the first one that shows up.
Thanks, Steven!
When I go to the URL of the layer you listed above, it shows up fine. When I substitute https for http in the layer's url, however, I get an "access denied" error. Were you viewing/editing your story map over http or https? If you were viewing it over http, the error checking code would check the URL over http and it would think it failed (like it did for me when I manually entered the layer's URL). If the story map was over https, that error should go away (since it would check the layer over https). If you try it in both http and https, is that true for you?
Okay. I understand now. When I add the https:// to the address bar in the story map editor and when I open the link to the story map (like I sent you) after I let it load and say that there are issues, the "fix issues detected" goes away.
Two questions: will this happen when I create another story map, but from scratch (now that all of our server issues are fixed and we didn't have to update the rest URLs)?
Are there any viewing issues with having our layers be in https--for any one? That is, if I submit this to Esri for viewing at the UC, will it be okay?
OR...
Is there something else I should be doing instead?
Thanks for your help.
We decided to check the service URLs by the protocol of the app, instead of by their own protocol (so if the app is over http, we will check services over http, even if the service URL's protocol was https). In your case, this same issue should still happen for other stories when checked over http (as long as they are using services that don't work over http). Checking the story over https should correctly show the layers as working.
I don't see any issues with layers being https -- https services can be accessed from an app that is over http or https. In fact, the converse would be a "mixed content" problem -- if you had your service URLs over http but the app was over https, in many browsers the services would not be able to load for security reasons.
Hope that helps, and thanks for your feedback.