I am developing a web application that analyses gmail content. I have registered the application with a Google Cloud project and set readonly GMail access as a restricted scope. I have just three OAuth listed test users. The system uses gapi.client.gmail.* and has been working perfectly for at least 6 months. I understand I will need to migrate away from this library interface at some point.
Suddenly I am getting "403" error with message "Request had insufficient authentication scopes." and reason "ACCESS_TOKEN_SCOPE_INSUFFICIENT". None of the usage limitations are anywhere near being breached.
Does anyone have similar experience or any suggestion for a remedy?
Related
About 2 weeks ago, I found that my GCP project (using YouTube API) is being suspended for violating Google Cloud Platform Terms of Service or Acceptable Use Policy by circumventing quota restrictions via multiple projects acting as one.
I've deleted all other projects and submitted an appeal for 12 days ago, but the main project is still locked and no response from Google support.
I just keep receiving 2 emails from Google system when I submit an appeal again:
Thank you for your follow up. A member of our team will review the appeal for your Google Cloud Project and get back to you within two business days.
and
We have recently detected your Google Cloud / APIs Projects have been circumventing our quota restrictions via multiple projects acting as one and appears to be violating YouTube API Terms of Service (III.D.1.c).
You can fix the problem by taking the following steps:
Consolidate your projects behind one single project ID and delete the remaining projects
Once you've completed step 1, sign in to your remaining active project and submit an appeal
How can I solve the problem?
Thank you.
You have to wait and check constantly your email for any requested information from the Google side. Try to be as detailed as you can and try to provide as much evidence as possible. This process sometimes can take some time to be reviewed. If you have submitted an appeal, you just can wait and keep monitoring your mail. On the other hand, you can create a new Project.
My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).
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 am hosting some Web Applications in Google Cloud Platform using App Engine and those are for internal purpose only. One month ago I got a mail from Google Cloud Team, saying one of my apps needs verification. By based on their response I did some research and finally migrated all apps to the Organisation level as they mentioned in documentation (below link for reference). https://support.google.com/googleapi/answer/7394288#gsuite-app
But, yesterday also I got another notification regarding the same.
May I ignore this notification, or are there any further steps I need to complete?
As stated in this other documentation page:
If you're creating an internal web app for which [...] your project is
associated with a Cloud Organization that your users belong to, you
don't need to go through verification. Internal users of your
application won't see the unverified app screen.
If your application will only be used by internal users belonging to the same organization as where your project is located, you can ignore this message. It was probably triggered by the fact that your application is indeed not verified (although you do not need to do so).
So if that is the case, you will only need, as stated in the link you shared, to create an Organization and then migrate your existing project to that organization (then make sure that the users who will be accessing the app belong to the same organization).
Looking at the Google App Engine API, it seems that despite all its great features, the User API is extremely limiting. It seems you can only authenticate people who have a Google account, or use an OpenID account, or via some OAuth kung fu (handshaking with a Facebook account etc).
This appears to be a major stumbling block for anyone who wants a proprietary user base by creating user accounts within the application. In short, I don't want my users to have to use or create a Google account to access my app.
Has anyone else come across this limitation and has it been a deal breaker for using the GAE? Am I missing something? It is possible to deploy my own Spring based security etc within the app and use my own User API? Comments on this issue greatly appreciated. Thanks.
You're free to completely ignore the Users API and implement your own authentication system, as you would in any other hosting environment. Nothing about App Engine prevents you from doing so.
The Users API is just there as a convenience, in case you'd like to spare yourself the effort of re-implementing everything, and spare your users the inconvenience of filling out another sign up form and remembering another set of credentials.
You can always implement your own user management system.
In my application I have used spring-security for this purpose. spring security 3.0.1 works perfectly fine with app engine 1.3.5. There may occur some issues integrating other versions of both. I found below links extremely useful :
http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
http://www.dotnetguru2.org/bmarchesson/index.php?p=1100
http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c