I'm writing code to generate and download a private key for a Google Cloud service account.
Using the IAM API, I was able to create a service account, and my call to generate a key seems to be working. I get back a Service Account Key as described on the IAM API create key page, like
{
"privateKeyType": "TYPE_GOOGLE_CREDENTIALS_FILE",
"privateKeyData": "random-key-stringkajdkjakjfke", ...
}
I downloaded this file as a JSON response and am trying to authenticate with it:
gcloud auth activate-service-account --key-file=service-account-key-file.json
Unfortunately, I get an error stating
The .json key file is not in a valid format.
When I go though the Google Cloud Console flow (IAM & Admin -> Service accounts -> ... -> Create Key -> Create) I get a downloaded JSON file that looks like
{
"type": "service_account",
"private_key": "----BEGIN-PRIVATE-KEY-----",
"auth_uri": "https://gaiastaging.corp.google.com/o/oauth2/auth",
}
This file looks completely different than the response from the IAM API. Explains my error! Unfortunately, this format doesn't seem to be described anywhere. It's mentioned briefly in some docs. Is it a Google Credentials File?
I'd like to take the IAM response file/JSON and convert it to the second credentials file. I've tried writing some code to convert it, but there are some fields like "auth_provider_x509_cert_url" that I don't understand.
Perhaps converting the file is the wrong approach as well? More generally:
How can I generate a file and then use it to authenticate with gcloud?
How should I describe/distinguish between both of the above files? Why is each type of file useful?
About the two files:
A Google Credentials file and a Service Account Credentials file are the same thing - they're both the second type of file that I downloaded off the Google Cloud Console page. No great official docs pages on them, but they're referenced a lot. Probably also Application Default Credentials.
The JSON response from the IAM create call - this is just a response to an API call. It's not useful outside of parsing it with your application code.
To generate a Google Credentials file:
In the JSON response to the IAM create, there's a field privateKeyData. This field actually contains the entire Google Credentials file. It's just encoded as a base64 string. I just downloaded the file from HTML as
<a href="data:attachment/json;base64;charset=utf-8,THAT-LONG-privateKeyData-base64-string-here" download="service-account-key.json">
Download key
</a>
Or if you just want to confirm that it contains all the information quickly, copy paste the base64 privateKeyData field into a file google-credentials and decode it (on Linux) with:
base64 -d google-credentials
I was then able to run
gcloud auth activate-service-account --key-file=google-credentials.json
and got
Activated service account credentials for: [service-account-id#project-id.iam.gserviceaccount.com]
Related
I am trying to dowload files from this websit using One drive API in invokeHttp.
So I append suffix like this /me/drive/items/ICTRPFullExport-672212-23-11-20/content
However, I cannot download the file.
I put this website into the postman, it show 403 error. But I also configure the username and password in the invokeHttp.
How can I fix this?
I'm trying to upload and publish my Chrome Extension using Chrome Web Store API in Azure DevOps. I've been referencing the official Google guide but the problem is that it looks like it's outdated now. I'm failing at the step
To create the client ID and client secret, click on Create New Client ID, select Installed Application, and Other under Installed application type.
When I do this, I don't see option for "Other" in Application Type dropdown.
I've tried the following:
Choosing Web Application as Application Type
With this I'm not able to get an access code with this link:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob
it's resulting in "Error 400: redirect_uri_mismatch". If I add an authorized redirect URI in my Client ID settings, like 'localhost', and replace 'urn:ietf:wg:oauth:2.0:oob' in URL above with it, I'm able to invoke authorization process and get the code from URL. But when I try to make a curl request to https://accounts.google.com/o/oauth2/token to get the refresh token I don't receive a refresh token, I only get this:
{
"access_token": "",
"expires_in": 3599,
"scope": "https://www.googleapis.com/auth/chromewebstore",
"token_type": "Bearer"
}
Choosing Chrome App as Application Type
Pretty much the same happens here as in previous attempt, except I don't have to substitute the redirect URI in request for access code, but I also don't have Client Secret for this application type, so I just omit it. Anyways, it results in the same response that doesn't have refresh token.
When I enable Chrome Web Store API in dev console and try to create new credentials, it suggests to create API key instead of Cliend ID. But it doesn't look like this API can actually work with this key, I've tried sending it as query param, as a header, and I always get 401 result with "Login Required" message. But when I try to send a request with (invalid) token in a header I get meaningful response (smth like Invalid Credentials).
Apparently I do need to have access token to work with Chrome Web Store API but without refresh token I need to manually authorize my permissions and that's not acceptable because I need to use in my CI/CD pipeline. It looks like Google removed the option to just generate this info for such application types.
So, the question is, how can I get the refresh token to actually be able to continuously deploy the chrome extension?
Ok, so the trick here was to add two params to the request that you use to get the access code (not token):
&access_type=offline&approval_prompt=force
And so the link should be:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&approval_prompt=force
And Google should do better job in updating their docs.
I just added Google Places API Web Service to my project, added an API key (unrestricted, for testing) and I am copy pasting requests from the docs to try things out, for example:
curl https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=my_new_key
I only get Request Denied ("This service requires an API key."), but in the API console I do not see any errors. The key is really in the curl command line in my sample, the API is enabled in the console, the key is valid and not restricted. I cannot find a reason why this should not work?
Here are few things you could try...
API key is for the application but you should authorize that application in google before using it.
Check your API key again and see if theres any encoding required before using it.
Enable API from your google account.
See if theres any restriction on your API key for example :
Under Accept requests from these server IP addresses, enter the IP
addresses from which your key is to be accepted, one per line. You
may also enter a subnet using CIDR notation (e.g. 192.168.0.0/22).
Hope this helps..
Try this link.... very helpful
REQUEST DENIED with Google Places API KEY for Server Web used in an Android application
I'm trying to figure out how to upload a file to google cloud storage using rest API , i don't want to use the client Library .
i read the documents but it was not helpful for a beginner in this flied ,
anyone can give me a step-by-step how to do this ? and how the URL/header/body format should look like , if also can give me an examples that would be very helpful .
If you're not going to use any of the helper libraries and are also a beginner, the hardest part of implementing an upload to GCS will likely be authenticating yourself. Let's ignore that for now.
The simplest way to upload an object to Google Cloud Storage is to make an HTTPS call to storage.googleapis.com that looks like this:
PUT /your-bucket-name/your-object.txt HTTP/1.1
Authorization: (YOUR ACCESS TOKEN GOES HERE)
Content-Length: 20
Content-Type: text/plain-or-whatever; charset=utf-8
Host: storage.googleapis.com
User-Agent: YourApplication/1.0
This is a test file
That will upload a file named "your-object.txt" of type "text/plain-or-whatever" to the bucket "your-bucket-name", with the contents "This is a test file."
If your bucket allows anonymous users to upload files (you shouldn't do that), then just don't include the Authorization line and you're done.
Now, since you really don't want to use any client libraries, and that presumably includes Google's OAuth libraries, you're going to need to implement authorization yourself, so let me give you an overview.
First, though, if you want to try this out immediately, install the "gcloud" tool, login with "gcloud auth login", and the print an access token with gcloud auth print-access-token. Then use the Authorization header Authorization: Bearer whatever.gcloudprintedout. That way you can be off and running with GCS quickly. But the token will only last an hour or so, so you'll need to implement OAuth for real.
Google Cloud APIs use OAuth to handle their requests, which is a powerful but not simple auth mechanism. There's extensive documentation on how OAuth with Google works: https://developers.google.com/identity/protocols/OAuth2
And there's also more general information on authorizing Google Cloud requests: https://cloud.google.com/docs/authentication
If you are running your application on a Google Cloud technology like App Engine or GCE, auth will be somewhat easier, but I will assume you're running this on your own machine. I will further assume that you want your application to have its own identity, rather than simply having you log in as part of the upload flow. For such a case, you'll need a service account, which will have an associated private key.
The basic flow for a service account is that you will create a JWT request for access credentials, then cryptographically sign that request with your private key, then send that signed request to Google. It will return you a token that may then be passed to your actual upload request later. You can keep using that token until it expires, at which time you'll need to build another JWT request to request another token.
Again, the client libraries entirely take care of this whole process for you. I am describing the approach of implementing everything exclusively on your own.
You can find the same example here:
https://stackoverflow.com/a/53955058/4345389
in which I already explained how to upload a file to google cloud storage using rest API.
Thanks
I am trying to handle file uploads for a web app through cloud code.I am facing the following issues
We cant add third party middle ware such as busboy to parse
Express' built in function such as req.files doesn't seem to work with the body parser parse.com provides.
I don't want to expose my app key in the client code.
I wanted to know if there is any other way to handle this.
Parse Cloud is not a Node environment so it is not a surprise that it does not support nmp modules.
The middleware Parse provides for express.js does not support file uploads. Instead you need to send the file contents as base64 to your endpoint and create the Parse.File object from this data. more info here
Your app and client keys(except for master key) are PUBLIC INFORMATION and NOT secrets. This is clearly mentioned in the documentation by Parse and you cannot hide them at all. Use CLPs, ACLs and Cloud code to protect your data from unauthorised access.