Using a secure origin with browser-based Geolocation

3930
23
05-11-2015 10:03 AM
AndyGup
Esri Regular Contributor
4 23 3,930

Many folks are starting to notice a warning message in the latest versions of Chrome when running apps that use the browser's JavaScript Geolocation API. The warning says "getCurrentPosition() and watchPosition() are deprecated on insecure origins, and support will be removed in the future. You should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details."

There are several things to know about this message. You will still be able to test Geolocation locally on Chrome without needing to install a security certificate on your development machine when using patterns such as "localhost", "web.local", "192.168.x.x" and similar since they are considered Potentially Trustworthy. Additionally, if you are using blob:, file: and filesystem: URLs they will also continue to work as long as they were created in a potentially secure origin themselves. However, if you have apps that use data: and javascript: then those origins are not considered potentially secure and will most likely be blocked.

Chrome and Google have been consistently sending a message that the web needs to continue moving towards HTTPS for all traffic. It's reasonable to assume that at some point in the near future Chrome (as well as other browser vendors) will require a location-based JavaScript app hosted on a public-facing, production server to be served up via HTTPS.

Additional Reading

Google Web Security Group: Google Groups

The Chromium Projects: Prefer Secure Origins For Powerful New Features - The Chromium Projects

W3C: Secure Contexts

23 Comments
ChrisSergent
Regular Contributor III

Does this mean that HTML5 geolocation will no longer work in Google Chrome if it's http?

AndyGup
Esri Regular Contributor

Hey Chris, web apps using the Geolocation API via HTTP work for now in Chrome. Chrome and Google are pushing for all web apps to migrate to HTTPS so this isn't really a surprise. Here's an article with more background info.

ChristianSailer2
Occasional Contributor

Hi Andy

Google has just stopped today the Geolocation API!

All the Esri JS samples have stopped working..

Do you have already a working alternative?

AndyGup
Esri Regular Contributor

Interesting. I'm seeing a geolocation response object when the app is served from "localhost" using desktop Chrome and Chrome Canary. However the location information is missing along with "POSITION_UNAVAILABLE" messages and timeout errors.

I'll see if I can get clarification from the Chromium folks and report back.

AndyGup
Esri Regular Contributor

Christian, it looks like this may be a bug in either Chrome and/or the Google Location Service. The Google Location Service is what provides the browser with your location in absence of a GPS (e.g. when testing from a laptop).

You can follow the conversation with the Chromium folks here. As I get more information I'll post updates.

MeleKoneya
Occasional Contributor III

Thanks for this discussion.    I am still learning about using the LocateButton in the ArcGIS JavaScript API.

Does this mean that the application should be HTTPS:?    What about the map services used in an application?   Can they be HTTP?

Thanks,

Mele

AndyGup
Esri Regular Contributor

Mele,

For now apps using the browser's Geolocation API will continue to work on Chrome with HTTP, but they will trigger a security indicator. At some point in the future that will change and geolocation-based apps will no longer work on HTTP.

The best I can tell the Chromium team hasn't set a hard date, yet. You can read the implementation specifics in the latest working draft of the W3C Secure Contexts document. That's the document that applies to all browser vendors, not just Chrome.

The web is moving in direction of making everything HTTPS, and it's a security best practice to use HTTPS whenever possible. If one map service is HTTPS-based then all services used by the app will have to be HTTPS, it's an all-or-nothing proposition.

AndyGup
Esri Regular Contributor

New information update for Mac OS users as of Feb 2016.

If you are testing a geolocation-based web app on Chrome locally you will have to use 'localhost' or '127.0.0.1'. Virtual hosts on Apache will result in the Geolocation API throwing the following error: " Only secure origins are allowed" and you won't be able to get a location.

JoshWhite
Regular Contributor III

Andy,

I made security changes in ArcGIS Online to accept HTTPS connections only in order to fix this issue.  Now my map will not load as apparently my services are all HTTP and the app wont load with mixed content.  How do I fix this issue?  I tried to switch my settings back but the WebAppBuilder will not change the settings back.  It always redirects to HTTPS which again wont load.

AndyGup
Esri Regular Contributor

Hey Josh, sorry for the late reply. Not sure why, but I didn't get a notification of your post. 

Do you still have the problem or has it been resolved?

JoshWhite
Regular Contributor III

I worked with Support to get my maps running again but I have found no solution to the locate widget issue.  Switching to HTTPS at this time is really not an option.  This is really a bummer because using the locate widget on a mobile device in the field was very nice.  

AndyGup
Esri Regular Contributor

Gotcha. 

Right, two other options are migrate to another browser or go to a hybrid approach. PhoneGap/Cordova uses plug-ins that can bypass the browser's Geolocation API, for example: cordova-plugin-advanced-geolocation.

FlavieMORAUX1
Occasional Contributor

Geolocalisation does not work in safari too. But on this browser i do not find information.

Do you have more information about this point?

Thanks,

Flavie

AndyGup
Esri Regular Contributor

As of Safari 10, insecure geolocation is no longer allowed. Unfortunately, Safari 9.x didn't give any warning messages about the up coming change.

The only place I had seen an official reference to this was in the Safari 10 Technology Preview Release Notes under Web APIs: "Started blocking Geolocation API calls on pages served over insecure connections". I'll make sure this info is passed onto the core JS API team.

Additional references on StackOverflow: ios10 - Got an error when trying to get the geolocation in safari on iOS 10 - Stack Overflow 

FlavieMORAUX1
Occasional Contributor

Thank for your answer.

Just on last question Do you know if it will happen also in IE and Firefox?

AndyGup
Esri Regular Contributor

Firefox is looking into similar functionality. You can read the details here under Bug 1072859 – Disable Geolocation on non-secure origins 

Not sure about IE. And, I haven't seen anything from the Microsoft Edge team yet. The status of Geolocation in Microsoft Edge is Shipped - Microsoft Edge Development 

FlavieMORAUX1
Occasional Contributor

Thanks Andy!

RachelAlbritton
Occasional Contributor III

Is ESRI doing anything to move AGOL hosted applications toward an HTTPS platform so that templates that use geolocation (i.e. GeoForm) can be accessible as a public app? As of now, our services are HTTPS but since we've created several public apps that require GeoLocation, they do not work as intended. 

AndyGup
Esri Regular Contributor

Hi Rachel, ArcGIS Online is already HTTPS-enabled. More details can be found here.

Quoting from that article, here’s the relevant bits that I believe apply to your question: “If you've disabled anonymous access to your organization, you can share maps, apps, and groups by sharing the item with everyone (public) and changing the URL of the item from your organization's private URL to the public ArcGIS Online URL (www.arcgis.com). For example, you could share one of your organization's maps with anonymous users by changing the URL from https://samplegis.maps.arcgis.com/home/webmap/viewer.html?webmap=fb39737f95a74b009e94d2274d44fd55 to https://www.arcgis.com/home/webmap/viewer.html?webmap=fb39737f95a74b009e94d2274d44fd55.

Does that help?

JoshWhite
Regular Contributor III

Why does changing the url have any affect?  Both of them are HTTPS.

AndyGup
Esri Regular Contributor

Josh, the name pattern in the URL determines whether or not anonymous will work with ArcGIS Online. Only the anonymous access approach allows both HTTP and HTTPS. Here are a few examples to hopefully illustrate the point a bit better.

Example 1: this uses the ArcGIS Online organization's name in the URL and it will prompt you for a log in. There is no anonymous access using this pattern and it requires HTTPS: https://hack4co.maps.arcgis.com/home/webmap/viewer.html?webmap=06a23f2572014ebcbbbb1953688d2724 

Example 2: this uses, HTTP plus www.arcgis.com in the URL and is open for anonymous access, no log in required: http://www.arcgis.com/home/webmap/viewer.html?webmap=06a23f2572014ebcbbbb1953688d2724 

Example 3: switch out HTTP in Example 2 with HTTPS and this webmap still works for anonymous access, no log in required: https://www.arcgis.com/home/webmap/viewer.html?webmap=06a23f2572014ebcbbbb1953688d2724 

EmilyLee2
New Contributor III

Hi Andy,

I've tried many Apple devices and it seems that anything newer than iOS/macOS 10 version doesn't work on a not fully secure website.  I have this GeoForm (shorten url:  https://arcg.is/1zPTzq), the 'Locate Me' button doesn't work on any Apple device that has newer than iOS 10.  

Even though it is a HTTPS.  But from the Google Chrome browser, it says it's not fully secure and contact the site owner. Since it's a hosted feature and webapp, should I contact Esri Tech Support about it?

Thank you,

Emily

AndyGup
Esri Regular Contributor

Hi Emily, do you have a github account? Can open an issue on the GeoForm's github repository here: Issues · Esri/geoform-template-js · GitHub ? When you open the issue in github cross-reference this forum post: https://community.esri.com/people/agup-esristaff/blog/2015/05/11/using-a-secure-origin-with-browser-... 

That's a better place for this thread, and we can work with you over there to help resolve the issue.

About the Author
Sr. Product Engineer - ArcGIS API for JavaScript.