Looking at the Time Zone API quota limit option that says:
"Requests per 100 seconds per user"
Was trying to find a clear definition of user but to no avail.
My intuitive guess it's an IP address... yet would like to avoid unpleasant surprises.
Would be good to know what does user mean exactly. Any ideas?
I believe this is a confusion that comes from the fact that Google Maps APIs share the same developer console with Google Cloud Platform. The "Requests per 100 seconds per user" make sense in Google Cloud Platform, but I don't think they are really supported in Google Maps APIs.
If we check the documentation of Google Cloud Platform we will see the following explanation
To prevent individual users from using up your API quota, limit the number of requests per second per user for an API. Each API includes a default per-user limit, but you can modify that value as described in the previous section.
Individual users are identified by a unique string; if you're creating a server-side application (where the calling code is hosted on a server that you own) that makes requests on behalf of users, your requests must include the quotaUser parameter, as described below.
To identify a user, use the quotaUser=userID parameter. This value is for short term quota enforcement only, so you don't need to use a real user ID. You can choose any arbitrary string under forty characters long that uniquely identifies a user.
The quotaUser parameter is only used for capping requests per user per second. If you don't send the quotaUser parameter, then all calls are attributed to your server machines, in which case calls can't be capped by user.
source: https://cloud.google.com/apis/docs/capping-api-usage#limiting_requests_per_second_per_user
As far as I know none of Google Maps APIs support a quotaUser parameter, so this value doesn't make sense for Google Maps web services and as mentioned in the last paragraph Google Maps web services will attribute usage to server machines. In other words to IP addresses of your backend servers.
I hope this clarifies your doubt.
Related
We have hundreds of users and we occasionally get blocked because we exceed the quota for UrlFetch. Is it possible to increase this limit? Or is there another workaround so we don't get throttled?
If I am not mistaken, it is possible, you would need to associate your script with a standard project from GCP (in case you have not done this yet). What I mean by this is that you need to create a separate project on GCP, then enable the APIs and configure the scopes and everything manually, and then associate it with your script from the script settings (see screenshot).
After all that just go to the project, then IAM & Admin >> Quotas and click "Edit quotas". This is also officially documented here and make sure that billing is enabled for the project.
What you would be doing with all this is submitting a request for the Google team in charge to review it and decide if approve it or not. It can take a couple of days for you to get a response from them.
I can't guarantee that the quota that you need to increase would be available, but at least this is how you can request any quota increase for any script you may have.
If you already have a project from GCP with the Apps Script API enabled, you can just follow the instructions to submit the request without having to follow the other steps.
So, I created an script on google sheets that, basically, selects a set of addresses on a sheet and uses Maps.newGeocoder.geocode() to get geocodes and calculate distances. It works wonderfully, no problems there. However, when I try to authenticate using Maps.setAuthentication(clientId, signingKey);, I just get an error.
I got my credentials from loging into https://console.cloud.google.com/, creating a random project and by going in "Create credentials". When I go into the credentials tab, I can select OAuth2.0 and see clientId and client secret key. I am using these to authenticate. Is it correct? What am I doing wrong? How the hell can I get the credentials? Thanks a lot!
The setAuthentication(clientId, signingKey) method enables the use of an externally established Google Maps APIs Premium Plan account, to leverage additional quota allowances. Your client ID and signing key can be obtained from the Google Enterprise Support Portal.
They are not the same as client ID and client secret key as explained here.
Note that this type of account is not longer available for new customers.
Here some helpful links:
Premium Plan Support
Premium Plan FAQ
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
My website makes use of Google Maps API. I recently received an email from Google that says that I should switch from a Browser Key to a Server Key in order to continue using the API past 2 Dec 2015.
So if I am not mistaken all I have to do is request a Server Key in the Google Console and put it in place of my Bowser Key? is that simple?
Here is part of the email:
Yesterday, we announced a pay-as-you-go option for seven of the Google
Maps API Web Services for free, external, publicly available websites
and mobile implementations. As part of this launch, we are tightening
security around how developers identify their usage of the APIs. You
are receiving this email because you may be affected by this change.
Starting today we have deprecated usage of 'Keys for browser
applications' or 'Browser keys’ with the Google Maps API Web Services.
Developers should instead use ‘Server keys’ with these services. Any
newly created browser keys will not work, but existing browser keys
will continue to work for 90 days starting today. On 2nd December
2015, we will be completely disabling usage of browser keys to access
Google Maps API Web Services, at which point any requests to Google
Maps Web Services APIs using such keys will begin to fail.
Currently, in my HTML I have the following that loads the Google Maps API:
<script scr="https://maps.googleapis.com/maps/api/js?v=3&signed_in=false&key=MY_BROWSER_API_KEY&sensor=false"></script>
In another page in the same website, I use the YouTube Data API in the server side to which I feed the SERVER_KEY I obtained from Google Console.
The code looks like:
require_once 'google-api-php-client/src/Google/autoload.php';
$client = new Google_Client();
$client->setDeveloperKey(GOOGLE_API_SERVER_KEY);
$youtube = new Google_Service_YouTube($client);
Yes, all you have to do is change out the key. There are complications with white lists, that may or may not affect people. The white lists between server and web keys need to be merged. This is a problem if the server does not send outgoing communications with the same ip address everytime. For example, for my company, our set up is a group of instances that get dynamically assigned ips from a public pool. In our case we are going to add an extra network interface.
So a better answer to your question is depending on whether you only use the key in a public webpage, or if you use it on a server. If you use the key on a server, and the key is connected to a paid google account for a specific map api service, then you will have to figure out the outgoing ip address(es) and add each one to the list.
A lot of people, particularly on shared hosting accounts have not white listed the server ip as until now, as it could be hidden and the risks of people pirating the key were minimal. But now, in the next 90 days, a lot of private server keys are going to be publicly exposed when people also have to put the key in their html. This will probably mean that there will be a mini migration from shared hosting to more controlled environments, in my opinion.
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?