The more you know!

[Dimu Designs]

Figured I'd start a topic where community members can share information about the many quirks and "gotchas" GAS developers are not commonly aware of.

Here's my entry for the day.

I stumbled upon this particular oddity a few weeks ago when a client asked me to resolve an issue.

It turns out that if your application leverages gmail scopes, those scopes are automatically invalidated when a user changes the password on that gmail account. The client in question had changed their password which triggered an authorization prompt. Something to watch out for.  

Feel free to contribute your own "gotcha" experiences.

[Martin Hawksey]

Nice callout on Gmail scopes. 

For me when publishing as a web app and forgetting to increment the published version or use the dev url has lost me time in the past.

[IMTheNachoMan]

Do you know if this applies to a trigger?

User creates trigger on GAS code and authorizes the a Gmail scope and then, after the trigger is created, changes their password?

[IMTheNachoMan]

For me the risk/issue with sharing code tied to authenticated triggers is not overtly obvious to folks. In fact, when we brought it up with our company's Google liaison and explained the risk they acknowledged it is unobvious.

Basically, if you give someone else edit access to a script where you own an authenticated/scoped trigger, you are giving them access to the scope. 

Imagine a scenario where there is a team on G Suite enterprise is using GAS for some team purpose/function and there are two developers, User 1 and User 2:

• Emails get sent to the team and they need to be "processed" using GAS
• They don't have access to service IDs, and, honestly, the average/novice developer won't think they need it (more on this below)
• User 1 creates a script that uses GmailApp.search(...) to search for emails in their (User 1) Gmail with the word "query" and uses GmailApp.sendEmail(...) to send an email to User X from their (User 1) Gmail account
• User 1 creates a trigger to run the script every hour and, as part of the trigger creation process, authorizes the appropriate scopes (e.g. Gmail)
• User 1 gives User 2 edit access to the code because both of them are developers on the same team working on the same project/automation
  
• At this point, User 2 could modify the code to search for "confidential" and send an email to User 2. Since the trigger is already created and authorized by User 1, for the relevant scopes (which User 2 didn't change) the updated nefarious code would run under User 1's identity. Meaning, it will search User 1's Gmail for "confidential" and email User 2 all from User 1's Gmail account.
  

I know the documentation says that triggers run under the owner's account and you should only give edit access to code if you trust them but there is a very fine line in saying I trust someone to edit the code vs. being able to make "trivial" changes to do things like change Gmail search criteria.

GAS becomes a double edge sword: it makes it super easy to create automation, and Google is all about collaboration so giving folks edit access is just a given. So you've got loads of novice developers using GAS for the first time and they won't realize that by giving someone else edit access they are inadvertently giving access to their Google identity.

I wonder how many organizations using G-Suite have novice/inexperienced GAS developers giving edit access to their code -- code that is tied to an authenticated trigger.

At first I thought we could use triggers created against specific deployed versions but for some stupid reason whenever you deploy a new version, all triggers will be automatically updated to the new deployed version. A feature request was submitted for this so I guess we'll see what happens: https://issuetracker.google.com/issues/145770681.

This was a big gotcha for me when I first realized it. You basically have two options: either you accept the risk and give other folks access to your Google identity (i.e. Gmail, Drive, etc...) or you don't collaborate which means nobody can support you if you're unavailable.

On Thursday, December 12, 2019 at 8:01:55 AM UTC-5, Dimu Designs wrote:

[Efficient Small Business]

You could get around this specific issue by using libraries and segregating them by permission level. This will allow your developers to do the work they need without giving them access to sensitive scopes. Depending on your situation this may not be the best solution, but if security and collaboration take precedence, it works.

[IMTheNachoMan]

Yes, that works for some use-cases. But I think it would be more common, especially for small teams/use-cases, that all developers would need access to all of the code. 

The thing is, there are some very easy ways for Google to address this. Some ideas:

• Idea 1: Triggers are invalidated as soon as the code/project it is linked to is modified. That way, if User 2 modifies the code, they could/would just create their own trigger since User 1's trigger would now not fire. And the new trigger that User 2 creates would only have access to User 2's Google identity -- thereby keeping User 1 protected.
• Idea 2: Require all triggers to be created at a deployed version and stop triggers from automatically updating to the newest deployed version (a trigger should stick to the deployed version it was created with). That way, User 2 can make as many changes as they want and the trigger will continue to run against the version that User 1 deployed when User 1 created the trigger. If User 1's trigger needs to be updated to point to a new deployed version, User 1 would have to do it which would give them an opportunity to make sure the code changes User 2 made are not nefarious. If User 1 is not available then the G-Suite admin can delete User 1's trigger so User 2 could create their own. This could even be something that G-Suite admins could configure for their domain: if triggers have to be created against a deployed version and to not auto-update to the newest deployed version.

There are probably other ways to address this risk/issue. But I don't think it is a priority for Google. I suppose it wont be until some bad actor at an organization that uses G-Suite takes advantage of a novice GAS developer and does something nefarious.