Does anyone know what are the "single account SMTP plugins" referenced here in this Google OAuth API policy?
See the last bullet of the "Exceptions to verification requirements":
SMTP/IMAP/WP: The app is used to send emails through WordPress, or similar single-account SMTP plugins.
Answer
Single-account is one account connected to your project or the only sender in it and SMTP plugins refers to the plugin that uses this OAuth token in order to send messages.
In summary, the bullet SMTP/IMAP/WP means that if you are using WordPress and set it up to be able to send emails using Gmail scopes, this is relegated to a single account SMTP plugin use and is not applicable for verification. Otherwise if your app is meant for public use it might require using https://mail.google.com/ scope, you will need to submit your app for the restricted scope verification.
Related
When attempting to use Google federated authentication login button for a Google webapp, error message identified mismatch with related URI and javascript host domains. Solutions, as in this 2019 post (Get gmail address using Google Apps Script, Error: redirect_uri_mismatch) weren't working for me.
I then found this recent article: What is the Authorized Javascript Origin for a webapp powered by Google Script?
I understand it to say that, due to recent actions by Google, it is no longer possible to use the Google authenticator for a Google webapp because redirect URI and javascript origin host domains "cannot be googleusercontent.com”, which is the host domain for Google webapps.
So, my question duplicates earlier posts (i.e., 2019) but in new circumstances. The conclusion of the recent post I've cited seems so radical to me that I'm seeking confirmation, or explanation of how I am misunderstanding it.
As background: I need the webapp to operate under the "(me)owner" account for connectivity to owner spreadsheets, but also need the user's Gmail address (required) for application access control (no other access to user Gmail account; users not all in a shared Workspace domain). Google login would provide the user Gmail address. So, before totally abandoning this solution, I hoping to get additional clarification.
According to the official docs, it's not possible to use Google Sign-In for Websites, and this post from the Google Apps Script Issue tracker Fail to Add *.googleusercontent.com into Authorized JavaScript origins as Google Apps Script uses googleusercontent.com
To achieve your goal, as I mentioned in your previous question, you might use the UrlFeth service to call the Google Sheets API to do the connectivity to your spreadsheet and setting the web app as the user instead as you.
From https://developers.google.com/identity/protocols/oauth2/web-server#uri-validation
Domain
Host TLDs (Top Level Domains) must belong to the public suffix list.
Host domains cannot be “googleusercontent.com”.
Redirect URIs cannot contain URL shortener domains (e.g. goo.gl) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback”.
Related
How to Properly Configure GAS Web App (as another user) to Execute GAS API Executable (as me) using OAuth2?
User access request when GAS run as the user
While true that you can no longer add googleusercontent.com, you may be able to solve this by using two webapps and managing authentication/authorization between the two:
Webapp#1:
Run as: Me
Access: Anyone even anonymous
Webapp#2:
Run as: User
Access: Anyone
You may be able to create a jwt token from webapp#2 and verify it on webapp#1. As it is a custom solution, security may be questionable.
References:
Authenticate with a server - Here, webapp#1 acts as server and webapp#2 acts as client.
ScriptApp.getIdentityToken()
The "Find and delete malicious emails" page in the Google Workspace Admin Help Center states:
Using the investigation tool, you can identify all users in your domain that have received the message (for example, a phishing email). You can then use the investigation tool to delete the email from your users' Gmail inboxes (note that log data might take up to a few minutes before being available in the investigation tool).
From this, I understand that, assuming you have the right package, it is possible to use the investigation tool to delete the unwanted email from your users' Gmail inboxes.
Can I delete emails from my users' Gmail inboxes via Google App Script using the API? If so, how can I do that?
Currently it is not possible with the Investigation tool
But there is already an existing feature request for exposing the Google Workspace Investigation Tool programmatically.
I recommend you to "star" it to show Google that more people are interested in this feature - hopefully this will accelerate the implementation.
UPDATE:
In th meantime you can use a workaround, e.g. using a service account with domain-wide delegation as suggested by #TheAddonDepot
It is possible via DwDg(domain-wide delegation)
You have to create a service account and delegate domain-wide authority to that service account with the appropriate scopes. There are no explicit instructions for the Gmail API but you can use this guide from the Admin Directory API documentation.
You then use the service account credentials with the GAS OAuth2 Library to make calls on behalf of your existing users to the Gmail API. Note that you can't use the built-in or advanced services for Gmail, you'll have to call out to the Gmail REST API directly via UrlFetchApp.
First of all, sorry for my bad English :)
I am building a Gmail addon which integrates file uploading to an external website using their API. The API have an auth endpoint which uses plain authorization flow i.e. takes email and password of a user to authorize and return authorization token. That token is then used in the subsequent call of file uploading process.
My question is, it has been mentioned in gmail addon guide that an app should use oAuth when connecting to a third-party service. However, the related website's API do not have oAuth but use plain authorization flow. If I create a login form with email and password fields using the card service, would that be okay and approved by google to be listed in the addons directory? Creating oAuth on third party service is not in my hands
Thank you!
Q: would that be okay and approved?
My experience is that it is OK to use basic authentication (since a lot of APIs still use basic auth, it would be devastating if the use of API was prohibited), most likely you will be approved. However, if there ever be a version of the API that supports OAuth, please, migrate as soon as possible.
Caveats
You mentioned creating a login form in CardService - please, be aware that there are no "password"-style TextInputs, so all characters will be visible all the time + there isn't, as of yet, any support for input event, so you won't be able to emulate the behaviour easily.
If you are planning on storing the credentials, try to avoid using PropertiesService - it isn't considered a secure storage (though if credentials are to be entered only once, storing the token should be fine).
You will still be asked to implement the authorizationCheckFunction.
I have a gmail account that I want to use for one of our internal services. We have a server running and we want this gmail account to be used to send out an automated email to people who register.
Now, here's the problem. I have correctly configured my gmail id in the server and know that I am able to correctly ping the gmail smtp server. However,I always get stuck because gmail by default expects you to verify any new device you log in from using an OTP. In my case, this is the first time login from this server machine and hence this happens. I can see it in the logs as well - it brings up this device verification page.
Some questions:
Is there a way I can turn off this feature in gmail? I don't think this is the same as 2 step verification. I have turned it off. I have also enabled my gmail account to be accessible from non secure apps.
If not, is there a way to do the verification step via command line on my Linux server?
Any other smtp based email service I could use that does not have so many security features?
Lastly, I am doing this for a quick prototype. Therefore I am ok bypassing some of these aspects. However, I would definitely want to ensure that the access to my account is secure once this is productized. Any links on how we can do this from non google apps or services?
Thanks in advance!!
It sounds to me you have an application that needs to work on your behalf and do some gmail-related tasks.
If that's the case, why not use the Gmail API with Service Account impersonation?
In short, a service account can impersonate a real user. This is a process that does not require manual input after it's setup, so it's ideal for server-side usage, where you might not even have a UI to interact with.
Also, the Gmail API is much easier to set up than Gmail SMTP, and there are examples out there on how to do this with this setup. You can look at this answer for some references on what it would take.
I am making an addon (sidebar addon to Google Calendar) and the addon needs to call an API hosted behind a Google IAP (Identity Aware Proxy). IAP requires an openid token, and the id token needs to be granted from Google's OAuth2 service by using the audience parameter. I can get this working by including this oauth2 library, however the user has to login twice. First to the addon, and second to the IAP service. Since both logins are to Google, and with the same user, it seems possible for them to only need to login once. The ScriptApp service in apps script has a function getIdentityToken(), but that token doesn't work with IAP because it didn't use the audience parameter while generating the token. Does anyone know of a way to call IAP with a token derived from ScriptApp so that the user doesn't have to login twice? Without direct access to the refresh token, I wouldn't be able to create an id token with the audience parameter myself.
This is currently not possible. You, as a user, will have to undergo two different OAuth authentication flows in order to be able to use IAP within your application.
This is, as you properly described, due to the Add-on current authentication flow (which does not allow you to include the "audience" parameter) and the inability to retrieve the refresh token from the current session.
If you are interested in the possibility of being able to include your IAP as part of the Add-on authentication flow, I suggest you submit a feature request to Google's Public Issue Tracker (https://issuetracker.google.com/issues).