I've recently been migrating an App Engine (Go) app from Go 1.9 to 1.11. I've followed the steps in the
Migrating your App Engine app from Go 1.9 to Go 1.11 document, excluding the optional ones. I plan on doing the optional tasks later once I get this working.
I get the app to build and I can deploy it just fine. Most of everything works fine, with the exception of one API that is used to look up some info on a Google Play IAP. When I do that, I get the following error:
Error 403: Insufficient Permission: Request had insufficient authentication scopes., insufficientPermissions
I've checked, and the scope that I'm using is https://www.googleapis.com/auth/androidpublisher, which is still the scope listed in the Google Play Developer API documentation.
I'm using the App Engine default service account for the client by calling DefaultClient from the golang.org/x/oauth2/google library, which returns a client without an error
When I test the same code with Go 1.9, there are no authentication issues at all, and the API works. I'm guessing that these is something in the authentication setup which has changed but I can't find any documentation on it, nor on what I should do differently.
I have to imagine that a lot of people have had to do this migration, and I can't find any posts with this problem, so I'm lost as to why I'm getting it.
I think the issue is in the differences of runtime in Go 1.9 and 1.11. It doesn't seem to allow you to use Application Default Credentials anymore, you have to set them via a JSON file in 1.11. I found someone who had a very similar issue to you and they used a workaround by uploading a key and using that to get a Client.
Have a look here
Let me know.
Related
I deployed Java 11 app on Google Cloud App Engine, and app is running fine, I can see the home page in the browser, but when the app tries to call Microsoft Graph API (the HTTP call is executed by using Microsoft Graph SDK), I am getting runtime failure.
The failure relates to Google debugger, but I didn't even enable debugger. I found information that debugger is enabled by default when Google builds the container image. I have two options - either to figure out why I am getting 401 error for the debugger, and configure debugger properly, or disable debugger completely.
I tried to find information how to disable Google debugger for container image generation, but didn't find anything helpful. I also tried to find information how to configure debugger properly for app engine, and also was not able to find complete working instructions. Does someone know what I need to configure on App Engine to bypass this error:
java.io.IOException: Server returned HTTP response code: 401 for URL: https://clouddebugger.googleapis.com/v2/controller/debuggees/register
at com.google.devtools.cdbg.debuglets.java.GcpHubClient.registerDebuggee
Assuming your Java app is in an App Engine Standard environment and using the bundled services, then you are still using appengine-web.xml file for app configuration. As stated in GAE standard Issuing HTTP(S) Request documentation:
URL Fetch will handle all outbound requests and cause requests that you send to your VPC network or the client libraries to fail. If any of these scenarios apply to you, make sure that the url-stream-handler field in your configuration is not set to urlfetch.
This scenario includes Google Cloud Debugger Client for Java hence the HTTP error. As a workaround, you can omit the following line in the appengine-web.xml file:
<url-stream-handler>urlfetch</url-stream-handler>
I have a Quarkus application already deployed on Google Cloud Run.
It depends on MySQL, hence there is an instance started on Cloud SQL.
Next step in my deployment process is to add keycloak. From what I've read the best option seems to be Google App Engine.
The approved answer in this question gave me some good insight of what needs to be done ... mostly.
What I did was:
Locally I made a sub-directory in the main project.
In that directory I added the app.yaml and the Dockerfile (as described here for instance).
There I executed the said two commands: gcloud init and gcloud app deploy.
I had my doubts about this set up and they were backed up by the error I got eventually:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: The first service (module) you upload to a new application must be the 'default' service (module). Please upload a version of the 'default' service (module) before uploading a version for the 'morph-keycloak-service' service (module).
I understand my set up breaks the overall structure of the project but I'm not sure how to mix those two application with the right services.
I understand keycloak is a stateful application, hence cannot live on Cloud Run (by the way the intention is for keycloak to use the same database instance shared with the application).
So does any one know a more sensible set up, or what can I move in mine in order to fix it?
In short:
The answer really is in reading the error message (thanks #gaefan) - about the error itself it explains enough. So I just commented out the service: my-keycloak-service line in the app.yaml (thus leaving gcloud to implicitly mark it as the default one) and the deployment continued.
Eventually keycloak didn't connect to the database but if I don't manage to adjust the configurations that would probably be a subject to a different question.
On the point of project structure and functionality:
First off, thanks #NoCommandLine and #guillaume-blaquiere for your input!
#NoCommandLine the application on Cloud Run is sort of a headless REST API enabled backend. Most of the API calls are secured by keycloack. A next step in the deployment process would be to port an existing UI (React) client on the Firebase hosting (or on another suitable service - I'm still not completely sure which approach is best) and in order for the users to work with this client properly they must make an SSO through keycloak first.
I'm quite new to GCP and the number and variants of the available options are still overwhelming to me - one must get familiar with the nuances but I guess it takes time. So I'm still taking suggestions on how to adjust my project structure to fit better the services stack. Thanks!
I have had a Python-based Google App Engine app working great using Cloud Endpoints 1.0 for several years without incident. I have had nothing but trouble migrating to Cloud Endpoints 2.0.
Currently I'm in the following state after already clearing many previous hurdles described in other similar questions:
I have one version of my service called gce1 which uses Endpoints 1.0 and is set as the default service receiving 100% of my traffic. I can point API clients and the APIs Explorer to both gce1-dot-myservice.appspot.com and the default myservice.appspot.com and everything works fine. I can verify in the logs that anything that goes through here is using GCE 1.0.
I have a second version of my service called gce2 which is not receiving any traffic by default, but if I point an API client or the APIs Explorer to gce2-dot-myservice.appspot.com it works just fine, and I can verify in the logs that anything that goes through here is using GCE 2.0.
Great, right? So it would seem that all I need to do is migrate all my traffic to gce2 and I'm done.
But... when I do that everything breaks! The default myservice.appspot.com serves up 405 POST Method Not Allowed responses to my existing clients, and if I look at the APIs Explorer, suddenly it now shows a bunch of obsolete methods that I think are from years ago and are no longer used in my current API. I can't tell where those are coming from (they are nowhere in my code, and haven't been for years), and I can't get the default service to serve the GCE 2.0 API no matter what I do.
The biggest problem is that I have thousands of users in the wild that all point to the default API URL, so it isn't so easy to just have them start pointing to gce2-dot-myservice, and besides, it doesn't make sense that I can't make the new default the new default. I've been working on this migration to GCE 2.0 for months, the deadline for getting off GCE 1.0 is getting closer by the day, and Google Support has not responded since late last year on this topic.
I should also mention I have tried:
Pushing a new service with the GCE2.0 code directly to default
Pushing a new service with no API at all (to maybe clear a cache or something)
Pushing services with all different sorts of version names
None of these have worked, although I haven't done any of them allowing a long delay since I'm working on a live service with real users.
This issue is now resolved, so for most people it should no longer occur. However, in my specific case, I had a legacy API that was getting in the way and had to be deleted, which did require specific attention from a Google engineer.
If you have similar issues, visit issuetracker.google.com/issues/76031966 and comment there.
Thanks to #saiyr for help tracking this down.
I'm deploying, for the first time, an app on google app engine.
It seems to have succeeded, however when I go to my apps url I'm directed to the traditional "welcome" page from the default installation.
I do not have a "welcome" app. nothing about "welcome" is listed in my routes.py file.
so why am I directed to myURL/welcome/default/index ?
I can't even type in the direct url that I know I want to access without an "invalid request" error.
This also only happens when I upload and run from appspot.com, when I use the local development engine things are fine.
According to the dispatching rules, if you go to a URL without specifying an application, it will default to the init application, and if not found, it will then look for the welcome application. Also, if you used the standard app.example.yaml configuration file when deploying, the welcome application would have been included in your deployment (see the GAE deployment section of the book).
not much of an answer, because I still don't know exactly how the routing occurred, however I had the web2py app in 2 locations. On my local machine and on the web hosting server. I had been uploading the version from the hosting server to GAE. This one was failing. When I uploaded the one from my local machine things started to work.
So I must have had a discrepancy somewhere between the two I just couldn't find.
You must call your application: "init" and deploy it in GAE.
For example, if you have developed yourweb2pyapp, your main page will be yourweb2pyapp/default/index and your main page in GAE would be yourGAEapp.appspot.com/yourweb2pyapp/default/index.
But if you write in your browser yourGAEapp.appspot.com you go to yourGAEapp.appspot.com/welcome/default/index and this is the problem.
The simplest solution is that you call your application "init" instead of yourweb2pyapp when you deploy it in GAE. So you new main, and default page will be yourGAEapp.appspot.com/init/default/index
You can pack yourweb2pyapp and then import it as init.
You have to be careful with the internal links.
How do I setup Account Registration, Login, etc in Grails when developing for the Google App Engine? Normally I would use the Acegi plugin but I've read that it doesn't work with Google App Engine.
For reference, I'm using the Grails app-engine and gorm-jpa plugins.
Google App Engine allows you to manage users through their Google Accounts Java API. The page provides example codes which you can easily implement with Groovy.
Hope it helps.
You should take a look at this patch: http://jira.codehaus.org/browse/GRAILSPLUGINS-1233. I haven't used it yet but might be what you are after.
In my opinion, it is essential to create custom authentication instead of using Google Account API to create any viable application run on GAE.
So, I created my own solution to tackle this problem which you may interested to have a look at URL:
http://grailsfuse.vobject.com/
(You will hit http 500 error for first request, please wait for 30 seconds and refresh)
The missing part is the self-registration page and remember me feature. Please contact us (hyperlink located below the page of URL above) if you are still interested.
Wish to heard from you soon!