Here on console, I am able to see a total of 7 resources. Which does not match with the result got from the API call. With API calls I am getting 75 resources:
GCP Doc link
https://cloud.google.com/compute/docs/reference/rest/v1/addresses/list
Method GET:
https://compute.googleapis.com/compute/v1/projects/{project}/regions/{region}/addresses
Here for us-east1 UI console shows 1 entry and API gives 4 records.
EDIT
For region us-east1 there are 4 records:
As it was discussed at the comment section, you see mismatch between Cloud Console (image 1) and API request (image2) because UI shows you EXTERNAL IP and API shows INTERNAL IP.
To solve this issue you should follow API documentation Method: addresses.list and set required items[].addressType:
The type of address to reserve, either INTERNAL or EXTERNAL. If unspecified, defaults to EXTERNAL.
Furthermore, you can see EPHEMERAL IP via Cloud Console UI, but accordingly to the API documentation items[].address:
The static IP address represented by this resource.
Related
I changed the connection setting of one of my cloud functions to 'Allow Internal Traffic Only' setting.
I have my nodejs app running in the same project, same region as my cloud function. I removed 'allUser' access from my cloud function and added My-PROJECT-ID#appspot.gserviceaccount.com as Invoker of my cloud function.
But I am getting 403 error now when I am calling the function from my nodejs app. What can I do to fix this?
I followed this as guidance: here
------------------UPDATE----------------
Many thanks for explanation below. It has started making sense now. So My setup is as follows as of now:
Cloud function side:
I have added My-PROJECT-ID#appspot.gserviceaccount.com as function invoker and removed 'allUsers' as an invoker.
Under variables, networking and advanced settings I have clicked on 'Allow internal traffic only' and then under Egress settings I have added the connector which I created earlier with an IP 10.8.0.0. I have added my connector in the format : projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME and selected Route all traffic through the VPC connector
App Engine (NODE js) side:
When I make a call to the function when it was publicly available, I was using the given hostname. Now my POST request looks like the following:
const optionsCFS = {
hostname: "10.8.0.0",//process.env.CLOUD_URL,
port: 443, //(tried 28 as well)
timeout: 5000,
path: process.env.CLOUD_ORDER_SAVE_PATH, // remaining path
method: 'POST',
headers: {
'Content-Type': 'application/application-json',
'Content-Length': CFSdata.length,
//'charset': 'utf-8'
}
}
console.log('Going to call CF ')
const orderReq = https.request(optionsCFS, resCFServer =>
{ // Do something })
I get Error 502 - Bad Gateway.
When you set the traffic to internal only, you say to the Cloud Functions (or cloud run, it's the same behavior):
Hey, accept only the traffic that comes from the VPC.
However, you don't say:
Hey make my service only reachable through private IP and no longer through public IP
The difference is important, because even if you set your Cloud Functions (or your Cloud Run) with an ingress mode Allow internal traffic only, the service is still exposed on the internet, still reachable publicly, but the gateway in front of your service (GFE I guess, Google Front End), perform an additional check: "Do you come from the VPC?"
This check is based on the traffic metadata only present in the internal Google Network (that's also means that the traffic stay in the Google Cloud backbone, to keep these metadata).
So, I continue my explanation.... When you set a serverless VPC connector to App Engine, you can only route the private traffic to the VPC connector, compliant with the RFC 1918.
However, as explained, the Cloud Functions, and the Cloud Run, service are reachable on the internet, not on a private IP (compliant with the RFC 1918). And thus, your App Engine traffic don't go through the serverless VPC connector, and can't be accepted as "internal" traffic during the ingress check.
With Cloud Functions and Cloud Run, you can set up the vpc-egress value to private-ranges-only (similar to the default behavior of App Engine, route only the IPs in the RFC 1918 ranges) or all. It's this latest mode that you need to use to call a internal only service from Cloud Functions or Cloud Run.
We are using the bing translater api in one of our projects for performing translations. The end point we use to call the api is:
http://api.microsofttranslator.com/v2/Http.svc/Translate?text=
To be able to call the API one has to authorize using the https://datamarket.accesscontrol.windows.net/v2/OAuth2-13.
Sometime in the last few days this datamarket.accesscontrol.windows.net url has become unavailable because the domain name resolution fails.
Exception: System.Net.WebException
Message: The remote name could not be resolved: 'datamarket.accesscontrol.windows.net'
Is anyone else affected by this and know what is going on?
The datamarket domain, and the ability to sign up via the Azure datamarket has been replaced by a regular Azure service.
Visit https://portal.azure.com and sign up for the Microsoft Translator Text API to get an API key. More detailed instructions at http://aka.ms/translatorgettingstarted.
I have been reading about creating an API which can be used to upload objects directly to S3. I have followed the guides from Amazon with little success.
I am currently getting the following error:
{"message":"Missing Authentication Token"}
My API call configuration:
The role ARN assigned is not in the image, but has been set up and assigned.
The "Missing Authentication Token" error can be interpreted as either
Enabling AWS_IAM authentication for your method and making a request to it without signing it with SigV4, or
Hitting a non-existent path in your API.
For 1, if you use the generated SDK the signing is done for you.
For 2, if you're making raw http requests make sure you're making requests to /<stage>/s3/{key}
BTW, the path override for s3 puts needs to be {bucket}/{key}, not just {key}. You may need to create a two-level hierarchy with bucket as the parent, or just hardcode the bucket name in the path override if it will always be the same. See: http://docs.aws.amazon.com/apigateway/latest/developerguide/integrating-api-with-aws-services-s3.html
I have recently moved a project over to another server. The domain name is the same, it has just been pointed to the new server. The URL is exactly the same. Since moving the project over however I get this error when the app tries to connect to googles OAuth api.
{
"name": "Error calling GET https:\/\/www.googleapis.com\/analytics\/v3\/management\/accounts\/~all\/webproperties\/~all\/profiles?key=AIzaSyBKUP8JriiOnFnbJm_QYt_bHTMuHf-ilAI: (403) There is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. Please use the Google Developers Console to update your API key configuration if request from this IP or referer should be allowed.",
"url": "\/analytics\/statistics.json"
}
The obvious reason (based on the error message) would be that I haven't added the new server IP into the list of allowed IP's in the devlopers console under APIs & auth->Credentials->Key for server applications.
I have added the IP. I've checked the domain has propagated by pinging it and the new IP comes up which has been entered in the console so i'm struggling to work out why it doesn't work.
Has anybody come across this before that may be able to help me solve it?
Go to Project -> APIs & Auth -> Credentials -> API Key -> Create New Key -> Browser Key. It may take upto 5 minutes to reflect changes.
And it worked for me.
After you added your new server IP you need to generate a new API key from the Console. This message shows up when access in not properly configured. Look here and scroll down to "accessNotConfigured".
So, go to your developer console, Project -> APIs & Auth -> Credentials -> Public API Access -> Create New Key -> Server Key. Use this new key and you should be good to go.
I've had this problem for a while as well but finally solved it:
I noticed when trying wget http://bot.whatismyipaddress.com/ from my server it would actually return an IPv6-address, when on the API key's config page I had entered the IPv4-Address of my server. Once I added the IPv6-Address, my requests where finally accepted.
Go to Project -> APIs & Auth -> Credentials -> Public API Access -> Create New Key -> Server Key >> Accept requests from these server IP addresses (Optional) section,
then remove all the IP Address and Update it first, then try it. And, later you can add the specific IP address which did weirdly work for me.
I am working on a Symfony2 app. I'm using FOSUserBundle to handle authentication and recently integrated it with FOSUserBundle using this tutorial: https://gist.github.com/danvbe/4476697 .
The problem is:
I can login using the google api on localhost and everything works fine.
However when I try to login on a real server I get:
Error: invalid_request
device_id and device_name are required for private IP: http://<server_ip>/login/check-google
Request details:
response_type=code
scope=https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile
redirect_uri=http://<server_ip>/login/check-google
client_id=<my_id>
Google documents don't mention these two parameters. I tried to manually send a request with device_id being a UUID and device_name set to "notes". The response I get this time is:
Error: invalid_request
Device info can be set only for native apps.
Request details:
cookie_policy_enforce=false
response_type=code
device_name=notes
scope=https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile
redirect_uri=http://<server_ip>/login/check-google
device_id=4b3403665fea6
client_id=<my_id>
Now, what am I doing wrong?
Google will not accept a local (private) IP address when doing Oauth or API calls. My workaround was to add an entry in my Windows hosts file for the local IP:
\Windows\System32\drivers\etc
192.168.1.2 fakedomain.com
then register it with Google in their dev console. That appears as a "real" domain to them, but will still resolve in your browser or code to the local IP. I'm sure a similar approach on Mac or Linux would also work.
It really looks like your using the wrong flavor of oauth. device_id is used with Devices. I would really expect you to be using the WebServer flow. You may need one of the other flows as I don't see enough detail here to judge, but they all can be found at the links.