Home General

Trouble configuring Gmail REST plugin

Hi,
I got a very good summary of configuring the emailing of reports from RB user support several months ago, and SMPT works well, BUT I continue to be stymied getting the GMail REST plugin to work. This may be totally beyond RB, but before I simply disable the GMail REST option in my app, I wonder if anyone out there can point me in the right direction, either on the RB side, or maybe on the Google side of things. So here is what I have so far:

1) Googles OAuth 2 registration: starting with the help in RB, and pursuing numerous other help sources, I was able to verify my web site, supply my privacy policy link and numerous other steps. So I was given the values for the ClientID and the ClientSecret. It is not reporting any problems there but there is NO prompt or pla ce for me to enter the "RedirectURI". With numerous help searches I have found nothing useful. It looks like most of the users are oriented toward web apps, and maybe that is part of the problem. I have a desktop app in Delphi and run the non-network RB. It seems to me the purpose of the redirectURI is not so relevant, but I could enter one of my web pages for a message display if needed - just can not see how to do that!

2) Testing the email from report function with GMail REST plugin - It appears to accept the ClientID and ClientSecret, but after a while, I get an error about the missing or invalid RedirectURI. I have tried various things for that, like nothing at all, variations on "local host", or my own web site url that was registered and verified in OAuth2.

I also note that this is inherently possible from my machine setup, because when I use the SMTP or Thunderbird plugin, I can see that Thunderbird uses OAuth2 when it successfully send out the email. Also when viewing a PDF in Adobe, they offer the email option and it also accesses OAuth2.

Puzzled Scott

Comments

  • Hi Scott,

    Google is constantly altering their process and restrictions to access their API's however in my quick testing, the Gmail plugin is working correctly.

    When creating a new OAuth2 Web Application, you simply add your own Redirect URI near the bottom of the setup page.

    image

    In my quick testing, it is possible to define a "Desktop App" when setting up your credentials. In this case, you will not define your own Redirect URI and simply use the following value instead.

    urn:ietf:wg:oauth:2.0:oob:auto


    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • Wonderful. That worked! Your support outshines anything from Google. I am not sure I like the Google hurdles and lack of guidance. In the name of security they have so many hurdles, it keeps some honest people out, but lets the techies do whatever, it seems.

    So where did the magic uri-Re-entry for desktop apps you gave (urn:ietf:wg:oauth:2.0:oob:auto) come from? Is that a re-entry into my desktop app, or in the RB part or something? I ask because if RB or GMail, or Google, or Windows change something, will this URI Re-entry setting still be good?

    Another irritation is that even with my default browser running, it loads the MS browser to get the permissions entered - but maybe that is unavoidable.

    Scott
  • Hi Scott,

    Yes, the Google REST API documentation leaves something to be desired. That mixed with the fact that they change their restrictions and specifications frequently makes it difficult to support. I hate to say it but Microsoft (Outlook.com and OneDrive), and Dropbox API's are superior as far as documentation and ease of use.

    The following page is somewhat informative when working with OAuth2 and Google products.

    https://developers.google.com/identity/protocols/oauth2/native-app

    It is necessary to use the built-in Windows browser because it is called from Delphi and needs to be able to communicate back with Delphi (similar to TWebBrowser). This is not currently possible with other browsers.




    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • Your explanations helped to get everything working, but I still have two questions on using the GMail plugin.
    1. I see the built-in windows browser accessed is Internet Explorer, at least on my machine. I also have Edge installed, and wonder for the future, with internet explorer going away, will the call from RB go automatically to whatever the built-in Windows browser might be on any given machine, and does that return URI change if for example Edge is called upon?

    2. What scopes are requested by RB when going to the GMail API? In my testing, it appears that the scope request is for "gmail.compose" This is a restricted scope, and to "verify" such a beast, it takes many weeks and a fee of $15,000 to $75,000. So I need to leave it unverified, or is there a way that RB can ask for a lesser scope?? Unverified allows up to 100 emails (no problem), but also prompts the users with many scary questions about the unverified app dangers (that is a problem!).

    Is there another possibility that RB can run GMail requesting only the unrestricted scope of "gmail.addons.current.action.compose"? It seems like this could be the case if the PreviewInEMailClient option is True - meaning that the user is directed to their secure GMail drafts and can inspect/modify the email they are about to send in their own gmail account before they send. (But I can not find info on what "gmail.addons.current.action.compose" really does. I do know that emailing reports through RB now with only that scope does not get avoid all the unverified app warnings.

    Scott S.
    p.s. there is always a plan B. I may need to tell my GMail users to install Thunderbird or Outlook and link that app to their GMail.
  • edited February 2021
    Hi Scott,

    1. The short answer is no. Edge and IE are very different beasts. A control for Edge is not yet fully supported by Microsoft so it cannot be used in the same manner that we are using IE. It's likely that for future versions of Delphi and Windows, an Edge control will be able to be used. You can read more about Edge support in Delphi here. Note that the current version of Edge does not function with the latest version of Delphi 10.4.1.

    http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_TEdgeBrowser_Component_and_Changes_to_the_TWebBrowser_Component

    Google would like API users to move to a Loopback IP architecture which we are in the process of researching for a future release of ReportBuilder. This would remove the need to use a built-in browser for authorization.

    2. This is unfortunate and it appears Google made this change recently. Looking at the documentation on the endpoints we use, it appeared the 'addons.current.action.compose' scope would work. Upon testing however, it became clear that this scope is meant for Google Add-ons only. Currently Add-ons can only be developed in Apps Script.
    Google apparently plans to release endpoints so the Add-on API can be accessed from other outside sources (ex. Delphi) but this is still in beta. This could be a way forward for a future release.


    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • Thanks! Not as easy as it first looked on the Google and Delphi side, but now it all makes sense.
  • edited February 2021
    Success! This may apply to all users, or possibly I just got lucky.
    They verified my OAuth2 project with the scope 'addons.current.action.compose'. Initially running my software with the RB GMail Plugin still gave all the "unverified app" messages, but now (after their system finished processing?), I am running GMail from RB without the onerous restricted scope problems or unverified messages!
  • Sorry about any confusion. I thought I got lucky in avoiding the Gmail "unverified app" messages, but that was only because I was selecting the same Google Account as where the OAuth2 was set up (in the IE screen). So my users will have a lot of unverified warnings, unless I go the difficult and very expensive route of a restricted scope.

    In other words, the last word from Nico, a few messages ago, is the accurate state of affairs. This and my last couple messages could be removed, so Nico gets the last word. As Nico said:

    Currently Add-ons can only be developed in Apps Script.
    Google apparently plans to release endpoints so the Add-on API can be accessed from other outside sources (ex. Delphi) but this is still in beta. This could be a way forward for a future release.
Sign In or Register to comment.