So I'm trying to implement a simple location autocompletion with the google places api. I'm using the autocomplete service for this (see: https://developers.google.com/maps/documentation/javascript/reference/places-autocomplete-service).
What I'm doing right now is, creating an autocomplete token and renewing it if either 3 Minutes ran out (according to How long do the new Places API session tokens last?) or a place detail request was set (according to https://developers.google.com/places/web-service/session-tokens).
Now, I want to debug this and want to know if I did it properly.The dashboard on the google developer console counts every single request made though.
How do I know if it has an effect?|
If you implemented session tokens correctly in your application, in your billing report within the Google Cloud Platform Console you should see one or both of the following SKUs:
Autocomplete without Places Details – Per Session Autocomplete
(included with Places Details) – Per Session
If you didn't, you'll see this instead:
Autocomplete – Per Request
Note that this only applies if you use getPlacePredictions(). There are no session tokens for getQueryPredictions().
Hope this helps!
Related
Currently I am developing a Chrome-GMAIL extension which requires me to get the logged in user's first and last names. For experimentation, I have used the following goggle API (userinfo) and have successfully obtained the names I wanted:
https://www.googleapis.com/auth/userinfo.profile
However, using the userinfo APIs will cause a change in the OAuth2 scopes in my manifest. This change will in turn cause a permission-prompt to my existing users (if a domain wide delegation is not setup in place). Point being the idea of having more prompts in front of my user, or additional oauth scope is not really something I desire.
Currently our extensions use the following OAuth scopes and API :
Chrome's Identity API
Chrome's Storage API
GMAIL.modify
GMAIL.send
My question is, is it possible to get the first and last names using an API that is defined/allowed/provided for by any of the above scopes/permissions I listed? or is userinfo the only way to go?
Thank you very much.
Profile data like first name and last name is private data. You are corect that some Google apis give you access to some data that would normally require an extra scope. For email normally you would need to to request the email scope to get this back however the Gmail api does have an endpoint getprofile which will return the current users email address without you requesting the email scope.
However i am not aware of any apis that will give you access to the users first and last name without you requesting the profile or user.profile scope.
If you do decide to add the scope, I do recommend going though the people api rather then the userinfo endpoint as the data returned by the user info endpoint is not guaranteed to always return the name.
I have the Google Picker API implemented in an application, with the Google Drive view included. Currently, entering a search query in the search bar of the Google Drive view starts showing a drop-down with some file results included, like this:
search bar drop down
However, clicking the "magnifying glass" search button, or pressing enter, or clicking "search for all items containing...", all results in an empty picker, like this:
empty picker with no search results
I believe this is occurring because a call to https://docs.google.com/picker/pvr is returning this error as a response every time: &&&START&&&{"error":true,"errorMessage":"Internal error"}.
The parameters being sent to that /pvr endpoint are here:
start: 0
numResults: 50
sort: 3
desc: true
q: testing
cursor:
mine: 2
service: docs
type: NOT_COLLECTION
options: {"ff":true,"filterTeamDriveResults":true}
token: J********
version: 4
app: 2
clientUser: 1************
developerKey: A*************
subapp: 5
What I found is that manually removing the "filterTeamDriveResults":true key from the "options" hash and doing an ajax post directly resulted in a successful request, but for whatever reason that option is included with every request from the picker, and any time a request is made with that option included, it seems to fail with the same "Internal error" response. I'm wondering what the source of that option is, and if there's any way to remove it from our picker. As far as I can tell it doesn't seem to be controlled by any of the options in the JavaScript API that we're loading from https://apis.google.com/js/api.js?onload=onApiLoad.
This started happening to us last week as well after having been using the Google Picker API for years without any issues. Your clue about the filterTeamDriveResults key reminded me of something I had just read, about upcoming changes to the Google Drive API and Google Picker API:
Next, we’re introducing a new Drive API resource collection, called “Drives,” to replace the “Team Drives” resource collection. This new resource collection can help you create, delete, get, list and update your shared drives, and features all the same fields, resources and available methods as the “Team Drives” resource collection. If you have been using the “Team Drives” resource collection in your applications, consider migrating as soon as possible as all related fields for Drive API , Drive Activity API and Google Picker API, will no longer be supported starting June 1, 2020.
It doesn't seem related, at least not directly, but made me think that perhaps, the SUPPORT_DRIVES feature that I had seen here in the docs, could "disable" that other teamDrive feature (even though it's not really that, but still...). And indeed, that fixed it. Basically just:
new google.picker.PickerBuilder().
setAppId(appId).
addView(new google.picker.DocsView().setIncludeFolders(true)).
enableFeature(google.picker.Feature.SUPPORT_DRIVES)
...
One thing to notice is this warning when enabling this feature:
Before enabling this make sure to refer to Google Drive API documentation for enabling shared drives and make any necessary Drive Rest API changes.
Might be relevant in your case.
I have a website that uses address autocomplete on multiple pages--address book, shipping address, billing address. With the billing changes releasing next month, we can convert the Autocomplete process to use sessions instead of individual keystrokes. (https://cloud.google.com/maps-platform/user-guide/pricing-changes/#billing-changes)
How long is an AutocompleteSessionToken good for? The current page? An hour? Twelve? Permanently, with it counting against the limit each time it shows up in a new month?
If a session token does expire, and we send that token with a request, what's the result going to be? If the customer leaves a webpage open for a day and comes back to pick up, and our session data hasn't expired, how do we make sure they don't get autocomplete errors?
As far as I can see there is no official documentation regarding session duration for Places API in Google Maps Platform. I can share some information about sessions obtained from the technical support, however, it doesn't provide exact value for session duration and it looks like Google won't reveal the exact value.
First of all, if you use the built-in Autocomplete widget of Maps JavaScript API, it generates sessions for you automatically, so no need to worry about it.
If you create your own widget, you should be aware that sessions do not last very long. An autocomplete session includes some Autocomplete requests (to retrieve suggestions on a place as the user types), and at most one Places Details request (to retrieve details about the place selected by the user).
The same session token is passed to the Autocomplete and the subsequent Place Detail request.
A session starts with the first Autocomplete request (which typically happens when the user starts typing). Typically, a Places Details call is made after the user has selected one of the Autocomplete suggestions.
After a user has selected a place (for example, a Places Details call is made), a new session must be started, with a new session token.
A session token cannot be used for more than one user session. If a token is reused, the session will be considered invalid and the requests will be charged as if no session token was provided.
If session token is expired or invalidated you will be charged on the per keystroke basis. So each autocomplete request will be charged.
I hope you find this information useful.
As a customer of Google Maps, when we contacted their support team, an agent that worked with us told us that the timeout is 3 minutes.
I have generated a Google Map API Key using Google console and currently that has 'None' restriction. It works fine and I am able to consume Google Places API without any problem. I am using Ionic framework and my application is purely based on HTML and AngularJS (JavaScript).
Now as my key works as expected for some duration, it stops working all of a sudden after sometime. Google service returns 'UNKNOWN ERROR' as response for all calls. To resolve this I need to generate another key and without code changes everything works fine. I have used URL https://maps.googleapis.com/maps/api/js?key=AIzaSyDgM6rXXXXXXXXXXXXXXXXXXXXTA68vY5g&callback=&libraries=places and pasted it in browser and copied the content of the generated JavaScript in a file and referring it locally. Also FYI, I don't have any server side code with me.
Now I have precisely 2 questions.
Do I need to change my Google API key every week to keep it active? Or once the restriction is set to 'Android' or 'HTTPS' then the key will work as long as I want?
If I publish my app in Android store is it safe to place the Google API Key in app files (JavaScript or HTML)? Is there a better way of doing it? Google best practices says we should keep it outside root, but then how should I do it?
You might not have billing enabled on your project.
Without billing enabled you only get 1,000 free requests per 24 hour period (calculated as the sum of client-side and server-side requests).
After you enable billing you get up to 150,000 requests per 24 hour period free of charge.
It might be slightly confusing that JS API Places library usage counts against the Places API limit, but that is the case: the daily usage is calculated as the sum of client-side and server-side requests combined.
I am using Google Drive SDK for .NET. Everything is working as expected, except that whenever I get the permission feed for a particular document. I get the Id, kind, name, role, selflink and type fields on permission.
There is no mention of the email address of the user which is stopping me from recognizing by reading the permissions, whether a file has been shared inside the domain or outside of the domain.
I can't use Google Docs API to get the ACL on doc because I am writing an app for users over 200000 users and I will need speed which is provided by Google API Console.
What should I do?
Thanks
You can use the Documents List API to get the email addresses. I'm curious why you believe Drive is faster than Documents List, for most API calls they have a comparable response time.
https://developers.google.com/google-apps/documents-list/#retrieving_the_acl_for_a_document_file_or_collection
Thanks for the idea but can I use Document List API with the Service Accounts provided through API Console?
Why do I believe that Google Drive SDK is better? Because we don't have any control over Document List API where we can set QPS (Query per second) limits or not that I know of.
Secondly, with Document List API when you make request to servers, in the past I had to create a fault tollerent algorithm in such a way that if one request fails second should go after 2 seconds if that fails then make your next request after 5 seconds until 7 second delay.
So, I don't think that Document List API would be a good fit for processing documents over 200000 users everyday unless Google has changed the way their API used to behave?