Testing whether a gmail user has previously communicated with a given email - google-apps-script

An app that I'm developing needs to test whether, for a given email address, the user has previously sent or received email from the address on the user's gmail account. However, this should be done without the app having the credentials to the google account, and without allowing the app to get any other information other than a true/false result to such a query.
How can this be achieved?
The solution should, if at all possible, use some existing google service to minimize or even completely avoid setting up my own server app to facilitate this.
An initial idea I had for this: use a google apps script that will get an authorization by the user to access email, and then scan all emails to collect the set of unique recipients and senders. Then, those emails will be saved in such a way that some URL handler can practically instantly respond to a query about whether or not a specific email exists in this set.

It's a better architecture to have the app query Gmail directly for this information, instead of using an Apps Script web app as an intermediary. The new Gmail API's Users.messages.list() method allows you to search for messages, and the q parameter takes the same types of queries that the Gmail UI supports, such as "to:person#example.com". Additionally there is a read-only scope supported by the API, so that users can feel more comfortable with the app gaining access to their inbox.

Related

GMail API/Google Workspace Add-on to automatically process emails with my own API

I'm wondering if I can use the GMail API, or some Google Workspace Add-On to aautomatically handle emails received by a specific address.
I have my own web app API, and I'd like any email sent to a specific address to trigger an API call to my web app, without a user having to manually do anything. (I can only seem to find references to how to do this using a visual interface that a user must interact with)
Ideally, this would work for a group address, but an actual account works too if that's a limitation.
Cheers!

GmailApp for specific email or forced to use logged in email?

GmailApp.search is great for pulling emails but what if I want to access a specific Gmail account logged in or not logged in is this possible with GmailApp or maybe some other method I am unaware of? Or am I forced to use the email address the user is logged in?
Due to security and privacy concerns, GmailApp service as well as the rest of the services provided by Google Apps Script and Google REST APIs can only access the logged-in user's data. In order to access another user's data, he/she will have to manually log in using the oAuth2 flow. As an option, you may create a WebApp that the end-user would connect to and manually authorize your application to be run using his/her data.

GAS execute under the content of active user

Is it possible to use a Google form, develop a GAS script that executes on form submission but have it run under the context of the users submitting the form?
Users will be in a GApps for Business domain?
Will it need to be published as a web app using doGet(), even though there will be no UI?
Only webApps have the ability to run under user's authority and they have an authorization request feature to handle that case. A form has no way to ask for authorization so it won't be able to do anything (or to trigger a script that would do anything) in the name of a user without explicit permission. That's a basic security case and hopefully there will be no way to go around it.
I guess the only way to get what you want would be to create the form with UiApp or HTML Service and deploy it as a webapp running under user's authority, in that case your users will be asked for authorization to access the services you need.
note : you said "even though there will be no UI?" but the form itself is a Ui isn't it ?...

Using OAuth2.0 (Google API) on a kiosk

I'm trying to set up a PC in kiosk mode that will display a list of events from a Google Calendar. I initially wanted to use the Google API for this (be it the JS client, Python client or other), but it seems that all of these require the user to consent via a page in the browser. This is not acceptable because it's a standalone system--there is no user to click on anything. The system will be on a daily power cycle so a 'consent once run forever' is also not possible.
Is there a way to use the authenticated (OAuth2.0) Google API to access calendar data without any user intervention whatsoever (except just a one-time initial setup)?
Thanks!
That's exactly what OAuth should be able to do. You should do a onetime setup (start he flow, authorize the request and get the tokens) and then store the tokens. Once the tokens are stored, you do NOT need any more user action as long as you have the tokens. The tokens would then be used to retrieve the data from the Google Calendar.

Google Script OAuth for multiple users

I've created a Google App Script that handle 2 different OAuth connections.
1- Google itself to send mail on behalf of the user and access google docs (google api console used to get keys, secret)
2- gtraxapp wich is a timesheet cloud-based app. (Script is registered, got a key/secret, etc.)
The script is published as a web app. It works perfectly for my user.
When logged on a different user name, I can authorize Google OAuth without providing different key/secret, and emails will be sent from the actual user.
Problem happens with the 2nd app (gTrax).
Authorization seems to work. Running the function inside the script to authorize lead to a screen asking for permission, gtrax then appears in the account as a registered app (could revoke access if needed).
But, when running the app, I get a message saying I need permission to do this action (UrlFetchApp / simple get)
My question is :
Is this possible that I need to register each user to get a key/secret for everyone (and dealing with that in the script)...
Or do OAuth can be registered with 1 key/secret ?
In other word, are (should) key/secret linked to a single user or are they only a kind of RSA-like key pairs that, when verified, can be used to authorize any user.
My understanding is this. When you use built-in Apps Script functions, like MailApp.sendEmail, the Google Apps Script "environment" takes care for you to ask authorization for the user (1st time he access your app) and save and manage the oAuth tokens for you, so it all runs smoothly.
When you call an external service using UrlFetchApp, Apps Script oAuth authorization process works differently. The authorization is just a strange popup you get on the script editor, when you actually make the fetch call. It is not processed at "compile time" and asked before you run anything like the other services. But you also do this step only once.
The "gotcha" is that this different authorization process does not work when a user is running the app as a webapp. AFAIK it only works from the script editor itself or running directly from a spreadsheet.
If your users are just a known few, you could advise everybody to open the script editor (or a spreadsheet that contains it) and run an specific function that will just attempt the UrlFetchApp.fetch call so the popup shows up and they authorize it. Once this step is done, they can use the webapp normally. Apps Script will do the magic for you after that.
But if you plan to share this broadly, say at the Chrome Web Store, and don't want to ask every user to do this somewhat strange step, then you'll need to manage all the authorization process yourself. It means, you'll have to register your app with the third party service (if it's Google's, it's at the API Console), where you will receive a client id and a client secret. With those you'll have to place a "Authorize" submit button on your app html that will redirect the users to the 3rd party authorization url, providing the correct scope, etc. When they authorize it, the 3rd party will redirect the user back to your app providing a code token as URL parameter. You'll use this code to call the 3rd party oAuth service to get the real access and possibly refresh tokens that you'll have to use on your UrlFetch calls. You'll be responsible to save these tokens, refresh them when they expire and so on. Not a very simple procedure :-/
Oh, and although your app have only one id and secret, the tokens are per user. Which makes sense, since each call you do must be on behalf of a specific user and he *must* have authorized it.
I hope this helps.