The AWS documentation explicitly list the API calls that are logged here: Logging Amazon Comprehend API Calls with AWS CloudTrail and they seems not to be included, but at the same time there is an example here: Logging Amazon Comprehend Medical API Calls by Using AWS CloudTrail that shows DetectEntities.
Comprehend does log all synchronous requests to Cloudtrail. Thank you for bringing this to our attention. We are already aware of the issue and will be updating the documentation soon.
Edit - Documentation has been corrected to reflect all the APIs.
https://docs.aws.amazon.com/comprehend/latest/dg/logging-using-cloudtrail.html
Related
We're currently working on our API based on Google Cloud Functions together with Google's API Gateway.
As every customer who buys access to our API should get their own API key, I'm wondering if there's a ways to create those API keys using and API. What I want to achieve is that a customer is able to request an API key in their own settings, so klick a button, this triggers a function, generates a key and shows it to the customer in front end.
After searching for quite some time, I didn't find anything about how this could be built. It could also be that my approach to this is totally wrong - if that's the case, please roast me and give me some advice with it!
Thanks in advance for your answers!
Google credentials can not be created programmttlcy they must be created manually.
In fact, there is something. A while in beta (more than 1 years ago) and quickly back in alpha, and undocumented (or pretty bad)
As you can see in the gcloud alpha command, you can use API Keys with CLI and API. Use this command to test and discover more how you can use API keys.
gcloud alpha services api-keys create --display-name="created by API" --log-http
USE WITH CAUTION
Firstly, I have no update on this API, will it survive or not? The lifecycle and the "no news" from Google is strange and keep in mind that the API can be removed at any time.
Secondly, API Keys is a long lived token and it's not recommended for security reason. But sometime, it's better than nothing, so to use it when no others solution are possible, it's acceptable. Else, prefer OAuth .
Eventually, API Keys authenticate a project, not a customer/user. You won't have it in header data after the API Gateway request forward. Only the Project ID (or Number, I don't remember). Thus, if you want to differentiate each customer/user, you need to create different projects, and generate a keys in each project. Same thing if you implement rate limit on API Gateway: Quotas are per project and not per API Keys.
In other words, what part of Google Cloud Endpoints is not in the SDK?
I've seen several people saying that simply running their application elsewhere doesn't work. For exaple, see: https://groups.google.com/forum/#!searchin/appscale_community/endpoints/appscale_community/BFagV00RUcU/taaAoV5mxNEJ
What part of Google Cloud Endpoints is not in the SDK? Are there any initiatives going to try to implement that?
Endpoints has two components. The first is the SDK, and the second is the API proxy. In theory, both could work on other platforms, but the reality is that you would need to really understand the finer details of the interaction between the two to execute it. You could also in theory try to use the dev server servlets to run on other platforms. I make no guarantees about the robustness of either solution.
Background: This is my first standalone web development project, and my only experience in Meteor is building the Discover Meteor app over the last summer. I come from about a year of CS experience as a side interest in school, and I am most comfortable with C and C++. I have experience in python and java.
Project so far: I'm creating a calendar management system (for fun). Using accounts-google, I have created user accounts that are authenticated through google. I have requested the necessary permissions that I need for my app, including 'identity' and 'calendar read/write access'. I've spent the last week or so trying to get over this next hurdle, which is actually getting data from google.
Goal: I'd like to be able to make an API call to Calendar.list using a GET request. I've already called meteor add http to add the GET request functionality, my issue comes with the actual implementation.
Problem: I have registered my app on the developer console and set up Accounts using the client ID and secret, but I have not been able to find/generate my 'API key' for use in the request. Here is the google guide for creating the access token by using my (already) downloaded private key. I'm having a hard time wrapping my head around an implementation on the server side using JS because I don't have a lot of experience with what is mentioned in the HTTP/REST portion of the implementation examples. I would appreciate some help on how to implement a handshake and receive an access token for use in my app. If there is a call I can make or some package that will handle the token generation for me, that would be even better than implementation help. I believe an answer to this would also benefit this other question
The SO answer that I've been referring to so far: https://stackoverflow.com/a/14543159/4259653 Some of it is in spanish but it's pretty understandable code. He has an API key for his request, which I asked this question to help me with. The accounts-google documentation isn't really enough to explain this all to me.
Also an unrelated small question: What is the easiest way to deal with 'time' parameters in requests. I'm assuming JS has some sort of built-in functionality that I'm just not aware of yet.
Thanks for your research. I have also asked a very similar question, and right now I am looking into the package you recommend. I have considered this meteor-google-api package, but it looks abandoned.
Regarding your question about time manipulation, I recommend MomentJS. There are many packages out there; I am using meteor add mrt:moment
EDIT: MomentJS now has an official package for Meteor, so use meteor add momentjs:moment instead of the mrt command above
Below is a snippet of what moment can do. More documentation here.
var startTimeUTC = moment.utc(event.startTime, "YYYY-MM-DD HH:mm:ss").format();
//Changes above formatting to "2014-09-08T08:02:17-05:00" (ISO 8601)
//which is acceptable time format for Google API
So I started trying to implement all of this myself on the server side, but was wary of a lot of the hard-coding I was doing and assumptions I was making to fill gaps. My security prof. used to say "never implement encryption yourself", so I decided to take another gander for a helpful package. Revising search criteria to "JWT", I found jagi's meteor-google-oauth-jwt on Atmosphere. The readme is comprehensive and provides everything I need. Following the process used in The Google OAuth Guide, an authorization request can be made and a key generated for making an API call.
Link to Atmosphere: https://atmospherejs.com/jagi/google-oauth-jwt
Link to Repo: https://github.com/jagi/meteor-google-oauth-jwt/
I will update this answer with any additional roadblocks I hit in the Google API process and how I solved them:
Recently, I've been running into problems with the API request result. I get an empty calendarlist back from the API call. I suspect this is becuase I make an API call to my developer account rather than to the subject user. I will investigate the problem and either create a new question or update this solution with the fix I find.
Fix: Wasn't including the 'sub' qualifier to the JWT token. Fixed by modifying JWT package token generation code to include delegationEmail: user.services.google.email after scope. I don't know why he used such a long designation for the option instead of sub: as it is in the google API, but I appreciate his package nontheless.
I'm quickly becoming proficient in this, so if people have meteor-related google auth questions, let me know.
DO NOT USE SERVICE ACCOUNTS AS POSTED ABOVE!
The correct approach is to use standard web access + requesting offline access. The documentation on the api page specifically states this:
Typically, an application uses a service account when the application uses Google APIs to work with its own data rather than a user's data.
The only exception to this is when you are using google apps domain accounts and want to delegate access to your service account for the entire domain:
Authorizing a service account to access data on behalf of users in a domain is sometimes referred to as "delegating domain-wide authority"
This makes logical sense as a user must be allowed to "authorise" your application.
Back to the posters original question the flow is simple:
1) Meteor accounts google package already does most of the work for you to get tokens. You can include the scope for offline access required.
2) if you are building your own flow, you will go through the stock standard process and calls as explained on auth
This will require you to:
1) HTTP call to make the original request or you can piggyback off some of the internal meteor calls : Package.oauth.OAuth.showPopup() -- go look at the source there are more nifty functions around there.
2) Then you need to create an Iron router server side route to accept the oauth response which will contain a code parameter that you will use to exchange for tokens.
3) Next use this code to make a final call to exchange the "code" for the token + refresh_token
4) Store these where ever you want - my requirement was to store them not at the user level but multiple per user
5) Use a package like GoogleAPI this wraps up Google API calls and refreshes when required - it only works when tokens are stored in user accounts so you will need to rip it apart a bit if your tokens are stored somewhere else (like in my case)
I use APIGee for both API Proxy and Documentation, using a customized documentation site.
Following the recent APIGee outage this weekend, when I access my registered application list using my personal login on the documentation portal, I can no longer retrieve my application keys.
I get the error
STATUS: 404 - Not Found; Communication with the Apigee endpoint is
compromised. Cannot get API Products List.
The strange thing is that if I use my admin login at accounts.apigee.com, I can see 2 of my 3 applications listed... but one has disappeared. And more worryingly, this portal provides different application keys to the ones that were initially provided though the documentation portal.
I haven't been able to find any good documentation on this. How are these two sites linked together? Why are the keys different on both sites? What has caused my data to go missing?!
Tadhg -
This sounds like an issue that needs investigation by Apigee Global Support.
Would you please create an Apigee Support case? Please provide any applicable details, including your Organization name, the API call(s) you are making, the 3 applications you expect to see, and any other details you think might be helpful to diagnose.
Thanks!
I have a custom Windows service developed in C#.NET that synchronizes users' Google calendars with an internal calendar.
Per the Google Calendar API documentation, I'm using the below code. I believe this is referred to as the ClientLogin method which may or may not be advised (I've found conflicting information in the Google documentation).
CalendarService service = new CalendarService("Your app name");
service.setUserCredentials("username", "password");
This worked fine in testing. Now that things have moved to production, I'm receiving errors such as "The user has exceeded their quota, and cannot currently perform this operation" and "User has modified too many events today. Please try again tomorrow." This began more than a day ago and has remained as such.
I've researched this considerably and am still confused on a few points. Any help would be greatly appreciated.
What is the daily quota per user?
Are the (really low?) quotas there because an API key isn't being used by my application?
If I were to use an API key, which approach would I use for a Windows service in which I have the usernames and passwords for the Google users? - Simple API, OAuth2, Service Account, etc.
FYI: I am using the API .NET library provided by Google. If I should be using a particular authentication approach, I would appreciate a sample illustrating the implementation using the .NET library provided via Google.
First of all you definitely don't use the latest version of the library. You can download it from NuGet. You should download the following two packages:
https://www.nuget.org/packages/Google.Apis.Calendar.v3/
https://www.nuget.org/packages/Google.Apis.Authentication/ (be aware that in the next release we are going to improve the OAuth2 flows significantly, and support WP, Windows 8 application).
Regarding your questions:
1-2) Calendar API supports 100,000 requests/day. You can find that information in the Google API Console in the services tab.
3) Definitely OAuth2. Read more here and here.
You can find code samples with the current implementation of OAuth2 in our samples repository (https://code.google.com/p/google-api-dotnet-client/source/browse/?repo=samples)