I maintain some plugins that allow developers to use the Google Maps javascript API. It is the developer's responsibility to supply their API Key when they build apps using my plugins.
In my sample code and applications where the key must be entered, I put in examples like "(enter your API key here)" or "API_KEY" because these are checked into the publicly accessible source code repository. At the moment, my plugin simply passes this string to the Google Maps API "as is". The only validation I do is to test that some value has been entered.
I want a simple test that will (with reasonable accuracy) determine whether a given string is NOT a real Google Maps API key. So far I haven't seen any documentation from Google indicating what to expect the string to look like.
I don't care if my test sometimes gets false positives, because the developer will get a Google Map error at runtime if they don't have a valid key. I do care about false negatives, however; if they supply a valid Google Maps API key, but my code falsely blocks it as "invalid", that would be a failure on my part.
All the valid Google Maps API keys I've seen seem to be exactly 39 characters long, consisting of the characters AI followed by 37 alphanumeric characters or dashes, e.g.:
AIjlSyEI1n03b7-this-is-fake-5tHcDxy1RnI
Would I run the risk of penalising anyone if I simply tested that the candidate key is at least 39 characters long?
What if I tested that the first two characters are AI?
What if I checked for the existence of characters like (, ), or _?
(if you have seen a valid Google Maps API key that does not conform to the above "rules" I've made up, could you comment? That would help to invalidate my hypothesis.)
(as MrUpsidown pointed out, the documentation does not state any rules one way or another - so the only perfect method would be to call the API - but in my case I want code that will run in isolation on the server side)
You should not rely on string validation because the way API keys are formatted could always change and like you said, it would give a bad customer experience to display an error message for a valid API key. This is a potentially useful feature to get though so I recommend you file a feature request in Google's issue tracker. For now all you can do is call the API to catch any errors should the request fail like MrUpsidown suggested.
Hope this helps!
Related
We are currently trying the Google places autocomplete api, but it seems as though Google places autocomplete api also returns invalid (non existent) addresses in the search result.
We want to receive only valid / actual addresses when the user types in the address autocomplete, is there a way to do it?
I searched the api docs but couldn't find anything much helpful.
There is a google places validation api but it only validates after given a single address, but we want to show only valid/actual addresses on search autocomplete and also don't want to call validation api for each of the search result items.
Went through official doc and also experimented several stackoverflow answers but those didn't match our requirements.
SO ref-1
This is Working as Intended as of now
I tried reproducing the Autocomplete request using this:
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=332%20Kennedy%20drive,%20Torrington,%20CT&types=address&key=API_KEY
And the results returned has a long Place ID.
According to the Places API documentation:
"Place IDs uniquely identify a place in the Google Places database and on Google Maps."
The documentation also says that the API may return a different place ID in the response. These place ID types include:
Street addresses that do not exist in Google Maps as precise addresses, but are inferred from a range of addresses.
Segments of a long route, where the request also specifies a city or locality.
Intersections.
Places with an address component of type subpremise.
These IDs often take the form of a long string.
This explains why the API still returned a street address for the input =332 Kennedy drive, Torrington, CT using types=address. The use case of autocomplete is to help the users obtain the closest result even if they are requesting an ambiguous query. So the Autocomplete always tries to return the closest result to their input and types. In your case, it returned a street addresses that do not exist in Google Maps as precise addresses, but are inferred from a range of addresses.
There's a public bug on the issue tracker that is somehow related to this. On the comment #5, it says that:
Suggestions are sometimes created for addresses that may not exist, if there are chances that they do.
Retrieving details for such suggestions may result in the suggested address, if it actually exists or can be synthesized from existing data. Otherwise, the result may be a different address, one that actually exists.
Possible workaround
One thing you can do is to use the validation API.
But since you mentioned that you don't want to use it, I tried the Autocomplete request using this:
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=332%20Kennedy%20drive,%20Torrington,%20CT&types=establishment&key=API_KEY
I just changed the types=address to types=establishment and it seems to return legit addresses. I'm not sure if this would fit on your use case, so you can just comment down if it does not.
And if it does not, I found a similar public bug on the issue tracker which says that similar issues like these are currently being worked on by the Google engineers internally. So what I would advise you to do wait for on update from this public bug.
There's no definite timeline on how long this will be fixed, but you can star it to be notified whenever there's an update.
Hope this helps!
== UPDATE ==
I tried playing around with the types and got to a point where I tried putting an array of types from this table. I tried this:
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=332%20Kennedy%20drive,%20Torrington,%20CT&types=street_address|street_number|premise&key=API_KEY
and it did return some real addresses. I changed the types=address to types=street_address|street_number|premise. You could try it out yourself and play around with the types and see if it works for your use case.
for more information about types, here's a link to the documentation.
In a standalone Desktop-application written in LiveCode (9.0.1, but I have the same issue in earlier versions of LiveCode), I am seemingly randomly receiving an error "Keyless access to Google Maps Platform is Deprecated. Please use an API key with all your API calls..." when attempting to get Geocodeing results with Google-Maps. I sometimes receive correct results with the same test address, and the same handler.
I am including a Google API, I have turned on billing with a valid payment card. I am still within the initial $300 trial credit, but I have enabled billing and have double checked that it is turned on. I have tried the API as both the value stored in an Variable and directly in the URL text. I have the API authorized for geocodeing, places, and static maps. It works flawlessly with the static maps. I have not tried with places yet.
put "https://maps.googleapis.com/maps/api/geocode/json?address=" & tAddress & \
"&Key=" & APIKey into ltTestURL
put JSONToArray(url(ltTestURL)) into aGeocodeInfo
I currently have a repeat block that tries, with a .5 second wait, until the request succeeds. It usually succeeds within a few seconds, but I would prefer to find the root of the problem.
Regards,
Geocodezip found it, the upper case K in "&key="
Perhaps use &key= (lower case key) in the URL – geocodezip
Thank you for finding my typo.
Here is the link I'm trying to access:
https://maps.googleapis.com/maps/api/place/textsearch/xml?query=restaurants+in+Sydney&sensor=true
According to some documentation on Google.com, it doesn't look like an API key is needed for their Maps service anymore. Can anyone see why the link I posted above wouldn't work?
If it does need an API key, could someone specific which API key is needed from Google?
In this case you should add a key
Required parameters
query — The text string on which to search, for example: "restaurant". The Place service will return candidate matches based on this string and order the results based on their perceived relevance.
key — Your application's API key. This key identifies your application for purposes of quota management and so that Places added from your application are made immediately available to your app. Visit the APIs Console to create an API Project and obtain your key.
sensor — Indicates whether or not the Place request came from a device using a location sensor (e.g. a GPS) to determine the location sent in this request. This value must be either true or false.
https://developers.google.com/places/documentation/search
Not exactly. Some of their APIs to not require keys with each request, but you must still authenticate. From their developer docs:
All Maps API applications* should load the Maps API using an API key.
You can read about the different APIs and their requirements here.
I am new to google map api. I copied the Hello_World.html from google maps javascript v3 getting started. But I always get the error message: the provided key is not a valid google api key.
I tried a few things but none of them worked. The following is what I did:
I edited the allowed referrers to mysite.com/* and localhost/*. But the error message is still there.
I tried a method someone suggested, which adds javascript version number:
change src="https://maps.googleapis.com/maps/api/js?key={XXX....X}&sensor=true" to src="https://maps.googleapis.com/maps/api/js?v=3.6key={XXX....X}&sensor=true", even so, the error message is still there.
Can someone give me any suggestions?
You do not need a key for Google Maps API v3, see the documentation. Your API v2 key will not work.
You will only need key for API v3 in case you want some additional features (very high traffic site, additional statistics etc.). But this is a very rare case.
You don't need a key, it should work without it. If you provided the key you are using (it isn't secret and can't be used on domains that you don't allow), we could tell if it is at least the correct format.
This
src="https://maps.googleapis.com/maps/api/js?v=3.6key={XXX....X}&sensor=true
is incorrect.
it is missing an & between the v=3.6 and "key".
version 3.6 is no longer available, that will result in the "frozen version", currently version 3.11.
I had this problem. The solution is:
Go to https://code.google.com/apis/console -> api access
Click "Key for browser apps".
The example says to enter *.example.com/* but it doesn't work for me. I had to enter (one per line):
example.com
*.example.com
*.example.com/*
example.com/*
Hope this helps
I have a server which acts as a mesh.
I have 3 mobile apps, each having it's own google maps api Key
all three apps call my server which calls the google apis with the specific app key.
so App1 has key1
App2 has Key 2
App3 has key 3
when I need the directions for App1, my server calls google api with key 1
when I need the directions for App2, my server calls google api with key 2
when I need the directions for App3, my server calls google api with key 3
So my server works like an API mesh. Is this against google terms? I am afraid they will look at the ip address of the server, see there are 3 keys used and assume I am using different Keys for same applications which is prohibited.
The short answer (drawn from the FAQ) is quite simply : no, you can't use two keys in this case.
See https://developers.google.com/maps/faq#usage_avoidance
- they even reserve "the right to withhold access to the maps API from any site" doing so, just as you feared.
Using more than one key, even though it could only be a matter of convenience for you, means for them trying to cheat and bypass the limitation of 25,000 requests per day and per service. And they don't like that, because they want big users of their maps API to pay, of course. Prices are listed on the same page.
You should read the FAQ paragraphs "Understanding the Terms of Service" and "Usage limits" completely - it is quite short but sometimes a little tricky. You'll see that there are a few situations in which you do not actually have to pay even when exceeding limitations :
you are using the google earth API
you are using a native maps API from a mobile platform
you are showing a google map through an embed only
your apps are "in the public interest (as determined by Google at its discretion)"
Also, you do not always need to provide an API key, though these products may still be available for limited use only : take for instance the geocoding API.
I guess you're not in one of those cases (at least bullets 2 and 3) since your calls transit through your server. Using the native APIs in mobile apps would solve the problem, but it does mean quite some development I guess.
It is also worth noting that you should apply for a special maps API for business license for some use cases, e.g. when only paying users get to see your map.
In conclusion, you need to have one single google maps API key when it comes to using their products that require one. Or rather, at most one per domain name.