"Access not configured" when accessing google cloud endpoints from web app - angularjs

I wrote a webapp with angularjs frontend, google app engine for storing data, and google cloud endpoints for api access from the frontend client. I tested everything fine locally, but after deploying, accessing the api from the frontend javascript client gives me the following error:
[
{
"error": {
"code": 403,
"message": "Access Not Configured",
"data": [
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured"
}
]
},
"id": "gapiRpc"
}
]
I've checked the production api explorer after deployment and it works fine. Also, I tried directly accessing the api by URL which also works fine. Just the frontend client does not work. Any ideas?

Turns out I set the API key in the client with gapi.client.setApiKey(API_KEY); where the API Key is the browser key from the cloud console. I removed this and it works fine. I have no idea what the API key is for.

I'm looking at the problem now on one of my projects. Might be that the ipv6 address must be registered for the project. Take a look at this post Google API returning Access Not Configured

The usual reason for this is that the API, which is being queried is not yet enabled in Google Console by the time of the request. Once it is turned on - error goes away.

Related

Duende IdentityServer 6.20 .Net6.0 "AuthenticationScheme: idsrv was not authenticated"

I have a fully functioning Duende IS6 solution, servicing an Angular client. However the Seq log output contains a lot of these entries with each request:
{
"#t": "2023-01-08T19:14:58.3783602Z",
"#mt": "AuthenticationScheme: {AuthenticationScheme} was not authenticated.",
"#m": "AuthenticationScheme: idsrv was not authenticated.",
"#i": "19c670d5",
"#l": "Debug",
"AuthenticationScheme": "idsrv",
"EventId": {
"Id": 9,
"Name": "AuthenticationSchemeNotAuthenticated"
},
"SourceContext": "Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler",
"RequestId": "0HMNHLIGV47GF:00000002",
"RequestPath": "/.well-known/openid-configuration/jwks",
"ConnectionId": "0HMNHLIGV47GF",
"application": "dev.identity"
}
Does anyone know what the issue is here? To be clear, my app functions and authenticates just fine so whatever it is doesn't appear to be causing an issue, just filling up my logs.
(apols for earlier version tag but could not tag identityserver6 as not enough rep)
The error is because ASP.NET Core did not find any cookie that it could convert into a ClaimsPrincipal user.
As you mention, requests to "/.well-known/openid-configuration/jwks" is never made by the browser, instead its made by the client and apis on the backend to retrieve the signing keys. And in these requests, there is no cookie to authenticate.

How to use ADFS Webfinger Endpoint?

I'm very new to ADFS and the Web Application Proxy. That said, I've recently setup an ADFS server and a WAP server and have all of the configuration setup to successfully handle SAML SSO to my custom application.
I am now attempting to use the Webfinger endpoint. By default, that endpoint is enabled (and proxy enabled). Unfortunately, I have not been able to get any meaningful response from this endpoint and am unsure even how to set it up. Searching for "ADFS Webfinger" documentation has been fruitless. Honestly, I can't find anything other than discussions of an Event Viewer error and other useless information.
I have attempted various combinations of URLs.
https://my-adfs-server/.well-known/webfinger?resource=https%3A%2F%2Fmy-adfs-server%2Fadfs%2F/ls&rel=http://schemas.microsoft.com/rel/trusted-realm
This gives me back a JSON:
{
"subject": "https://my-adfs-server",
"links": [
{
"rel": "http://schemas.microsoft.com/rel/trusted-realm",
"href": "https://my-adfs-server"
}
]
}
but it is the only URL I have found that returns anything.
https://my-adfs-server/.well-known/webfinger?resource=acct:<myemail>
This gives me a 404 with a valid email (acct).
What am I missing? Even if that last URL was working, how do I resolve it to specify information that should be returned in the JRD document for this particular account? Do I need IIS installed (I don't have it installed currently) and custom code?
Thanks for any help/insight.
Pink

App Engine Admin API Error - The "appengine.applications.create" permission is required

We would like to automatically create a project ID and install our ULAPPH Cloud Desktop application using the App Engine Admin API (REST) and Golang.
https://cloud.google.com/appengine/docs/admin-api/?hl=en_US&_ga=1.265860687.1935695756.1490699302
https://ulapph-public-1.appspot.com/articles?TYPE=ARTICLE&DOC_ID=3&SID=TDSARTL-3
We were able to get a token but when we tried to create a project ID, we get the error below.
[Response OK] Successful connection to Appengine Admin API.
[Token] { "access_token" : "TOKEN_HERE", "expires_in" : 3599, "token_type" : "Bearer" }
[Response Code] 403
[Response Body] { "error": { "code": 403, "message": "Operation not allowed", "status": "PERMISSION_DENIED", "details": [ { "#type": "type.googleapis.com/google.rpc.ResourceInfo", "resourceType": "gae.api", "description": "The \"appengine.applications.create\" permission is required." } ] } }
We are just using the REST API calls. Request for token was successful as you can see above and the scope is ok as well. Now, when we posted the request to create application, we are having the error that says "appengine.application.create" permission required.
How do we specify the permission?
What are the possible reasons why we are getting that error? Do we missed to send a field in JSON or in query?
As per below link, we just need to pass the json containing the id and location. We also just need to pass the token in the Authorization header. The same logic I have used successfully in accessing Youtube, Drive APIs etc so not sure what needs to be done since I have followed the docs available.
I have also posted the same issue in Google Groups and now waiting for their reply.
It seems you've given no details about how you set up the account you're using to authorize the request. You'll need to make sure the appengine.applications.create permission is given to the account you're using, as mentioned in the error text. You can use the Google Identity and Access Management (IAM) API for this.
(by the way, I'd given this answer in the original thread, although you didn't reply or seem to take action on it. check it out! this is likely the solution you need!)

Pinterest denying access from Google App Engine (403)

Using an oauth accessToken, I am able to retrieve the user's info through:
https://api.pinterest.com/v1/me/?fields=first_name%2Cid%2Clast_name%2Curl%2Cusername%2Cimage&access_token=xxxx
which from a desktop or even ec2 returns:
{
"data": {
"username": "yyyt",
"first_name": "yyyr",
"last_name": "",
"url": "https:\/\/www.pinterest.com\/yyyt\/",
"image": {
"60x60": {
"url": "https:\/\/s-passets-cache-ak0.pinimg.com\/images\/user\/default_60.png",
"width": 60,
"height": 60
}
},
"id": "1234567890"
}
}
However, when the same query is made from appengine, a 403 error is returned with the details:
{
"message": "Forbidden",
"status": 403
}
I can't find any information about why Google AppEngine may be specifically blocked, and since their API has come out of Beta, I'm not sure a reason why it would be.
This earlier question: Pinterest API - returning 403 on EC2 Instance suggested that they were blocking ec2 because the api was still unofficially supported, but ec2 access does in fact seem fine now, so I'm not sure why they would block google.
Can anyone suggest a workaround not involving a proxy, or refer me to a reason why the access might be forbidden?
or refer me to a reason why the access might be forbidden?
Unfortunately I ran into the same issue today when I tried to access the Pinterest web-site (not the API) via App Engine.
Looking at the 403 error page that is returned by Pinterest following a HTTP request from App Engine it seems that the reason is that Pinterest doesn't like bots and intentionally rejects HTTP requests by App Engine or the App Engine dev server.
When trying to access Pinterest via CURL, I noticed that Pinterest rejects all HTTP requests that have the string App Engine in the User-Agent HTTP request header, but Pinterest does happily accept any other (random) User-Agent string.
Because App Engine, as stated in the documentation, automatically appends the string "AppEngine-Google (+http://code.google.com/appengine; appid: APPID)" to the User-Agent HTTP request header, I suspect there is no way of circumventing this.

Is app_identity.get_access_token supposed to work in development environment?

I use this code to access Google APIs from my GAE app:
scope = "https://www.googleapis.com/auth/urlshortener"
authorization_token, _ = app_identity.get_access_token(scope)
It works well with production environment and doesn't work in development environment:
Using token InvalidToken:https://www.googleapis.com/auth/urlshortener:77.5780799389 to represent identity test#localhost
('Call failed. Status code %s. Body %s', 401L, '{\n "error": {\n "errors": [\n {\n "domain": "global",\n "reason": "authError",\n "message": "Invalid Credentials",\n "locationType": "header",\n "location": "Authorization"\n }\n ],\n "code": 401,\n "message": "Invalid Credentials"\n }\n}\n')
Is there any workaround I could apply (but not implementing OAuth from scratch)?
Upd. Another approach to access Google APIs from development environment also doesn't work:
credentials = AppAssertionCredentials(scope='https://www.googleapis.com/auth/analytics.readonly')
http = credentials.authorize(httplib2.Http(memcache))
service = build('analytics', 'v3', http=http)
response = service.management().accounts().list().execute()
logging.info(response)
Actually, dev_appserver.py recently added some arguments to make appidentity work during local testing. See Unable to access BigQuery from local App Engine development server for details.
The reason it works on appspot.com is because it uses the automatically created App Engine service account. Since the service account is associated with the app engine instance on which it is running, it's authority can be guaranteed. When you are running locally, there is no service account - how can they know you are debugging your own app as opposed to anyone else's?
If you want to run your code locally, you will need to implement OAuth, which actually is only a few lines of code anyway.

Resources