Update: It seems I'm not the only one having issues with Google's "verification process", especially for GMail applications.  See this article for more information.  My latest contact says they require a security assessment that could cost $75,000 or more, and conveniently provide a couple of companies that can do it (no collusion there I bet either).

In the end, if you are using the GMail addon for G4G, and want to continue, it looks like making them private is the best and only option.  And it is one that we can help with.

Whew.. it's been quite a busy spring and summer dealing with Google and their ever changing application processes as regards to the available API scopes, privacy, etc.  We also have had a few requests for just the base GreenTools for Google Apps (G4G) product so that customers can build their own API calls, using G4G for the OAuth 2.0 Token creation and refreshing.  The following updates are currently in process or already available:

G4G Base Product Availability And Licensing

We have been getting requests for the ability to use only the G4G Base Product for OAuth 2.0 Token creation and refreshing.  Because of this we will be soon have the Base Product available to users with ILE functions and a web interface that will allow customers to set up users for Google API functions as well as internal ILE procedures for refreshing tokens and much more.

This also means that the base G4G product will now also require licensing for current and new users.  

Also, because Google is tightening the use of many scopes for their APIs for public apps (see the following section for more information on that) we will be moving to setting up all G4G applications as private to your company instead of trying to set them up as public and trying to meet all the rules and regulations they are implementing after the fact in order to have a Google Verified Product.

Google Application Scope Privacy Updates

For the past year we have been dealing with Google (as have other app developers) to try and get our applications re-approved by Google.  In the past it was a simple process, but now, because of some mischief by some internet hoodlums (see this article) Google is taking the exact opposite approach.  They are asking developers that use certain scopes to provide some sort of proof that their applications require the requested scopes that they are using.

The main issue is with the GMail SMTP server and it's option to send email using the more secure OAuth 2.0 method vs the basic user id/password authentication methods.  From Google's own documentation, sending emails using OAuth 2.0 through their SMTP server requires the highest level scope of https://mailt.google.com which in effect gives the application access to pretty much do anything with the email account it's attached too.  

I've asked many times why they don't simply change the scope required to something less intrusive and they simply won't answer and suggest instead using the send email API.

The other issues are the G4GGMAIL addon for G4G that allows you to download emails from your GMail account using a simple command or ILE function.  This feature also has the option to mark email messages as read which requires the https://www.googleapis.com/auth/gmail.modify scope which, again, may seem obtrusive, but we're just following their rules.

Because of this any public application, such as G4G, much go through a rigorous process of proving the scope is actually required.  Google is requiring YouTube videos of these applications in action (which we have supplied many times!) and we keep getting the same response that we need another video for some reason.  (I personally think the reviewers at Google simply have never heard of the IBM i and are thinking that my app should be running on an Android phone or tablet and aren't used to seeing actual business systems that don't have  native web browser).

Needless to say, this is VERY frustrating.

Our Solution To This (For Now)

For now we are updating the G4G Application so that you can purchase the G4G base product to handle only the OAuth 2.0 registration process as well as token refreshing, which really is the most difficult part of the process.  

Also, right now our applications are stored as public applications under our own BVSTools.com domain through Google Apps for business.  The main reason Google is requiring such strong rules to get authentication.  So in the future we will be slowing moving customers to set up their own applications under their own Google Apps for Business accounts and making the private to their company which will not require the authentication process (at least for now... it seems you never know with Google!)

This does mean that each customer will require a public web interface for OAuth 2.0 callbacks on the same domain that they are using the applications for (most often your corporate domain).  This also means that you may require some extra work done by us to get this set up and possibly more help in the future should anything need updating or changing.  This will add to the TCO of the product, but also should make it easier to deal with the Google Privacy Policies.

So, feel free to contact us with any concerns or questions.  We will be sending out a newsletter with this information (and more) as well as providing current G4G customers with specific information they need.  I have a strong feeling that now they are locking down GMail so tight for public applications that Google Drive will be next.