保护链接到授权触发器的 Google Apps 脚本，以便其他人可以编辑
securing a Google Apps Script linked to an authorized trigger so others can edit
我很确定我的理解是正确的，但由于我找不到任何 Google 明确强调这一点的文档，所以我想在这里问一下。
根据 https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
而且我们知道，当您创建触发器时，它会要求授权脚本使用的所有范围。
那么，这意味着任何拥有脚本编辑权限的人都可以利用用于创建触发器的用户的 Google 身份来访问触发器授权的范围。
例如：
- 用户 1 创建了一个 Google Apps 脚本，该脚本使用 GmailApp 发送电子邮件
（即
GmailApp.sendEmail("one@example.com", "test subject", "email body");）
- 用户 1 每小时创建一个 运行 所述脚本的触发器，并使用适当的 GmailApp 范围对其进行授权
- 用户 1 授予用户 2 编辑 所述脚本的访问权限
现在，用户 2 可以进入所述脚本并更改代码并访问用户 1 的 Gmail 帐户。例如，用户 2 可以将代码更改为：
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
他们所要做的就是更改代码并保存；他们不需要重新创建触发器，因为它已经存在。下次触发 运行 时，它会 运行 newer/updated 代码。
我能够通过在我的一个帐户上创建测试脚本并授予另一个帐户编辑权限来确认此行为。
所以我的问题是，official/recommended 减轻这种风险的方法是什么？显而易见的答案是不给其他任何人编辑权限，但如果这不是一个选项怎么办——如果出于支持目的需要多人访问脚本，那怎么办？
正如您所说，唯一的 official/recommend 方法是将编辑权限限制在 受信任的 人。
在您的特定示例中，用户 1 可能选择了 MailApp 而不是 GmailApp。这两个看似冗余的服务可以单独使用，因为与 GmailApp 相比，MailApp 公开的权限非常有限。 （例如，用户 2 无法使用 MailApp 服务搜索受害者 Gmail。）
您可以进行协作，同时避免使用 clasp 和 git 直接访问您的脚本文件。只有你用 clasp 推送到脚本。其他人都通过 git 提交更改。您可以将系统设置为全自动（即 git push 触发 clasp push）或手动（即您首先查看所有更改），无论哪种方式，您都可以很好地记录谁做了什么，何时使用git.
当您提供对脚本项目的编辑权限时，存在固有的信任。你要么信任这个人，要么不信任他们。没有中间。
一些 "theoretical" 您仍然可以保护数据的方法：
- 创建和使用不同的 Google 帐户。
在 Head 的特定 deployment/not 安装触发器：
- 只有手动完成才有可能。以编程方式创建的可安装触发器只能用于
Head
- 部署web-app/api时，您可以将其部署到特定版本。
- 然后可以提供此部署版本，当您为项目创建新触发器时here。
- 不需要工作 web-app/api。我们只是想获得一个部署 ID。
- 这样，即使用户更改了脚本，您的触发器也只会 运行 在部署的旧版本上。
- 部署的版本可以在发布 > 从清单部署中看到。
如前一个答案所述，git 会更好。
出于所有实际目的，您与恶意实体共享的任何数据都应被视为已泄露。
我很确定我的理解是正确的，但由于我找不到任何 Google 明确强调这一点的文档，所以我想在这里问一下。
根据 https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
而且我们知道，当您创建触发器时，它会要求授权脚本使用的所有范围。
那么，这意味着任何拥有脚本编辑权限的人都可以利用用于创建触发器的用户的 Google 身份来访问触发器授权的范围。
例如：
- 用户 1 创建了一个 Google Apps 脚本，该脚本使用 GmailApp 发送电子邮件
（即
GmailApp.sendEmail("one@example.com", "test subject", "email body");） - 用户 1 每小时创建一个 运行 所述脚本的触发器，并使用适当的 GmailApp 范围对其进行授权
- 用户 1 授予用户 2 编辑 所述脚本的访问权限
现在，用户 2 可以进入所述脚本并更改代码并访问用户 1 的 Gmail 帐户。例如，用户 2 可以将代码更改为：
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
他们所要做的就是更改代码并保存；他们不需要重新创建触发器，因为它已经存在。下次触发 运行 时，它会 运行 newer/updated 代码。
我能够通过在我的一个帐户上创建测试脚本并授予另一个帐户编辑权限来确认此行为。
所以我的问题是，official/recommended 减轻这种风险的方法是什么？显而易见的答案是不给其他任何人编辑权限，但如果这不是一个选项怎么办——如果出于支持目的需要多人访问脚本，那怎么办？
正如您所说，唯一的 official/recommend 方法是将编辑权限限制在 受信任的 人。
在您的特定示例中，用户 1 可能选择了 MailApp 而不是 GmailApp。这两个看似冗余的服务可以单独使用，因为与 GmailApp 相比，MailApp 公开的权限非常有限。 （例如，用户 2 无法使用 MailApp 服务搜索受害者 Gmail。）
您可以进行协作，同时避免使用 clasp 和 git 直接访问您的脚本文件。只有你用 clasp 推送到脚本。其他人都通过 git 提交更改。您可以将系统设置为全自动（即 git push 触发 clasp push）或手动（即您首先查看所有更改），无论哪种方式，您都可以很好地记录谁做了什么，何时使用git.
当您提供对脚本项目的编辑权限时，存在固有的信任。你要么信任这个人，要么不信任他们。没有中间。
一些 "theoretical" 您仍然可以保护数据的方法：
- 创建和使用不同的 Google 帐户。
在
Head的特定 deployment/not 安装触发器：- 只有手动完成才有可能。以编程方式创建的可安装触发器只能用于
Head - 部署web-app/api时，您可以将其部署到特定版本。
- 然后可以提供此部署版本，当您为项目创建新触发器时here。
- 不需要工作 web-app/api。我们只是想获得一个部署 ID。
- 这样，即使用户更改了脚本，您的触发器也只会 运行 在部署的旧版本上。
- 部署的版本可以在发布 > 从清单部署中看到。
- 只有手动完成才有可能。以编程方式创建的可安装触发器只能用于
如前一个答案所述，
git会更好。
出于所有实际目的，您与恶意实体共享的任何数据都应被视为已泄露。