The new Places API Billing defines Sessions for merging Autocomplete and Place details requests, but the docs just say the API will merge requests with the same Session Token, made within some minutes.
I find this very vague!
Do we have to generate new Session Tokens or can we reuse the same and the API will group them anyway within time-windows?
Do we have to be aware of the lifespan of the Session Tokens?
Can the Session Tokens be any kind of string?
Google has all this answers, but is spread over a lot of different places and can be hard to find. To answer all 3 of your questions:
Do we have to generate new Session Tokens or can we reuse the same and the API will group them anyway within time-windows?
The session tokens cannot be reused from one session to the other.
Do we have to be aware of the lifespan of the Session Tokens?
The session begins when the user starts typing and ends when they select a place and you call the detail API. Once that happens you must generate a new session token for each new call to the autocomplete API.
Can the Session Tokens be any kind of string?
The Google Places API provides a class that you can use, but you don't have to. The class Google provides is called AutocompleteSessionToken it can be used liked this:
var token = new google.maps.places.AutocompleteSessionToken()
But you can also use your own string. See Google's recommendation
All this info is straight from the Google Docs, see below:
Place Autocomplete uses session tokens to group the query and selection phases of a user autocomplete search into a discrete session for billing purposes. The session begins when the user starts typing a query, and concludes when they select a place. Each session can have multiple queries, followed by one place selection. Once a session has concluded, the token is no longer valid; your app must generate a fresh token for each session. We recommend using session tokens for all autocomplete sessions. If the sessiontoken parameter is omitted, or if you reuse a session token, the session is charged as if no session token was provided (each request is billed separately).
Source: Google Documentation
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.
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!
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 two facebook applications with their own access tokens.
I have followed this guide to create a business and associate the aforementioned apps to this business.
I now have a token for business from doing a graph api call -
/me?fields=token_for_business
When doing a regular api call without referencing this token for business, I can return app scoped user ids who have been invited to events for example like so -
https://graph.facebook.com/v2.3/{FaceBookGroupID}/invited?access_token={MyAppsAccessToken}
Where MyAppsAccessToken varies depending on the app, thus resulting in different app scoped user ids being returned depending on what access token is used.
After getting the token_for_business I updated my call to -
https://graph.facebook.com/v2.3/{FaceBookGroupID}/invited?token_for_business={MyTokenForBusiness}&access_token={MyAppsAccessToken}
My assumption was that now the applications are associated to the same business and have a link token, the calls would have brought back the same user ids in the JSON response, however this is not the case and regardless of appending the token_for_business parameter to the url, the same JSON responses are returned as the first call.
Is it possible to return the same user ids with two different access tokens?
No, different Access Token means different App, means different App Scoped ID. You can only use the Token for Business to match different App Scopes.
Btw, the call with token_for_business as parameter does not make any sense. The token is for one user.
We are planning on migrating our Box v1 integration to v2.
Our integration implementation includes API calls accessing user box account and files from different servers at the same time.
With v2, and the introduction of refresh token, we would like to know whether multiple refresh token requests can be made concurrently from multiple servers over the same user account.
Moreover, and as a consequence of multiple refresh calls, we would also like to know whether it is possible to have more than one access key per user at any given time.
Thanks for the help
Assaf
We recommend that you use some sort of coordination between your servers to manage auth tokens and refresh tokens. While a user can have multiple access tokens for the same service, they will have to authenticate multiple times in order to get them. You can't mint extra auth tokens off a single auth-token/refresh-token pair.
Here's what we recommend.
Create a pair of encrypted columns in your database to store the auth token, the refresh token, a datetime for "token_expires", and a flag for "token_refresh_in_progress". Identify it by userID.
Write your code so that when you are about to make a call, if you are close (say, within a minute) of the token-expires datetime, instead of making your call, you check to see if the refresh-flag has been set, or if there's already a new token pair. If the flag hasn't been by some other server in the cluster, set the flag that you are doing the refresh. Make the refresh-grant call, and update the database with the new pair, and of course reset the flag.