We did notice today an issue in automatic detection of zip code based on the user s location. it worked well in other browsers(edge, IE, Firefox)
We had to configure the sites to https and then it works ok
Example : https://www.whatismyzip.com/ works well
where as http://www.mapdevelopers.com/what-is-my-zip-code.php does'nt work.
<script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=AIzaSyAdGQKI4sEj5TZAjNCds422V_ZHevD45Fo"></script>
<%-- <script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?sensor=false&libraries=places"></script>--%>
<%-- <script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?libraries=places"></script>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>--%>
<script type="text/javascript">
function ShowMessages() {
debugger;
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(success);
} else {
alert("Geo Location is not supported on your current browser!");
}
function success(position) {
debugger;
var lat = position.coords.latitude;
var lng = position.coords.longitude;
var latlng = new google.maps.LatLng(lat, lng);
var geocoder = geocoder = new google.maps.Geocoder();
geocoder.geocode({ 'latLng': latlng }, function (results, status) {
if (status == google.maps.GeocoderStatus.OK) {
if (results[1]) {
var searchAddressComponents = results[0].address_components,
searchPostalCode = "";
$.each(searchAddressComponents, function () {
if (this.types[0] == "postal_code") {
searchPostalCode = this.short_name;
}
});
document.getElementById('hidden1').value = searchPostalCode
__doPostBack('', '');
}
}
});
}
}
Any help/workaround would be appreciated.
EDIT: Other than Google API, are there any other working alternatives?
You cannot use the HTML5 Geolocation API with non-secure connections as per below:
Starting with Chrome 50, Chrome no longer supports obtaining the
user’s location using the HTML5 Geolocation API from pages delivered
by non-secure connections. This means that the page that’s making the
Geolocation API call must be served from a secure context such as
HTTPS.
However, it is possible to use the Google Maps Geolocation API or GeoIP, and possibly others, though it is not recommended in the long term. See below:
There are a number of fallback options available to get a user’s
location that are not affected by this change, such as Google Maps
Geolocation API, GeoIP (as an example, there are other geo based
solutions), and a user-entered zip code. However, we strongly
recommend that the best path to ensure ongoing access to geolocation
is to move to HTTPS.
Source: Geolocation API removed from unsecured origins in Chrome 50
Deprecating Powerful Features on Insecure Origins
Chrome Security originally sent this out to various browser development mailing lists. See the original intent-to-deprecate email on blink-dev. This is based on the original idea to prefer secure origins for powerful new features.
Proposal
We want to start applying the concepts in https://w3c.github.io/webappsec-secure-contexts/to features that have already shipped and which do not meet the (new, not present at the time) requirements. In particular, this approximately requires that powerful features only be accessible on "secure origins" (such as HTTPS
) where the full ancestor chain is also secure.
They have set to start by requiring secure origins for these existing features:
Geolocation — requires secure origins as of M50
Device motion / orientation
EME
getUserMedia
AppCache
As with gradually marking HTTP as non-secure, we expect to gradually migrate these features to secure-only, based on thresholds of usage, starting with lowest usage and moving towards higher. We also expect to gradually indicate in the UX that the features are deprecated for non-secure origins.
The deprecation strategy for each of these features is not decided on and may very well differ from feature to feature. We don’t currently know what the thresholds will be, or how heavily used the features are on what kinds of origins. We are in the process of gathering data, and will report back when we have it. There are no firm plans at all at this time, other than eventual deprecation. We intend for this to stimulate a public discussion of the best way to approach this deprecation.
Testing a Deprecated Powerful Feature
After a feature has been deprecated, if you are a developer that needs to keep testing a feature on a server that does not have a valid certificate, you have two options:
localhost
is treated as a secure origin over HTTP, so if you're able to run your server from localhost, you should be able to test the feature on that server.
You can run chrome with the --unsafely-treat-insecure-origin-as-secure="http://example.com"
flag (replacing "example.com" with the origin you actually want to test), which will treat that origin as secure for this session. Note that you also need to include the --user-data-dir=/test/only/profile/dir
to create a fresh testing profile for the flag to work.
The new Security rule introduced in Chrome 50
does not send Location Information to Sites without Transfer Encryption
.
Here are the alternatives which are apt for the Mapping API problems.
Reverting to Prior versions of the Chrome(50) is also a solution, but in Web development, it is quite difficult to do so.
But the fact is that, currently only Chrome has such issues with Mapping API
and other Browsers still supports them(Which gives me a short term peace of mind)
.
But sooner or later, this may be practiced by other browsers too, which may be a big problem for the existing users unlike me. Since it is a long term process(in my case), it is better to start developing and migrating to https sites rather than being in http, how ever there are pros and cons in handling them.
I know this isn't a place to debate but this answer probably represent most of programmers that have been implemented geolocation in their applications.
As stated in other answers "Geolocation API removed from unsecured origins in Chrome 50".
Well that is a weird move by Google.
They claim that the changes are due to user privacy.
This seriously compromises user privacy.
Google cares about user privacy(laughs).
I have developed numerous of applications (CMS plugins, standalone application templates) using HTML5 Geolocation API for public use.
I can't really say to 1000 users to get an SSL certificate.
From my point of view Google is trying to make internet more expensive and inaccessible for most of independent developers and "superusers".
Alternatives are:
I tried to load the geolocation script from an HTTPS location on the same server and from public accessed CDNs (github) but the same error appeared.
Chrome requires an SSL installed on the website too.