Granting access rights
If a script uses services that can access private data, you'll see one of the authorization dialogs shown here. Apps Script determines the authorization scopes (like access your Google Sheets files or Gmail) automatically, based on a scan of the code. Code that is commented out still generates an authorization request.
Scripts that you have previously authorized will also ask for additional authorization if a code change adds new services. Scripts do not request authorization if they use only services that cannot access user data (like the URL Fetch service or the Language service), or if you access the script as a web app that runs under the script owner's user identity.
Revoking access rights
To revoke a script's access to your data, follow these steps:
- Visit the permissions page for your Google account. (To navigate to this page in the future, visit Google.com, then click your account picture in the top-right corner of the screen. Next, click Account, then Security, then View all in the account permissions section.)
- Click the name of the script whose authorization you want to revoke, then click Revoke access on the right.
Permissions and types of scripts
The user identity that a script runs with — and thus the data it can access — varies based on the scenario in which the script is run, as shown in the table below.
|Type of script||Script runs as...|
|Standalone, add-on, or bound to Docs, Sheets, or Forms||User at the keyboard|
|Custom function in a spreadsheet||Anonymous user; however, quota limits count against user at the keyboard|
|Web app or Google Sites gadget||User at the keyboard or script owner, dependent on options selected when deploying the app|
|Installable trigger||User who created the trigger|
Manual authorization scopes for Sheets, Docs, and Forms
If you're building an add-on or other script that uses the Spreadsheet service, Document service, or Forms service, you can force the authorization dialog to ask only for access to files in which the add-on or script is used, rather than all of a user's spreadsheets, documents, or forms. To do so, include the following JsDoc annotation in a file-level comment:
/** * @OnlyCurrentDoc */
An opposing annotation,
@NotOnlyCurrentDoc, is available if your script
includes a library that declares
@OnlyCurrentDoc, but the master script actually requires access to more than
the current file.
Authorization lifecycle for add-ons
Add-ons for Google Sheets, Docs, and Forms generally
follow the same authorization model as scripts that are
bound to a document. In certain
circumstances, however, their
onEdit(e) functions run in a
no-authorization mode that presents some additional complications. For more
information, see the
guide to the add-on authorization lifecycle.
Apps Script Google Developer Console projects
Every new Apps Script project automatically creates its own project in the Google Developers Console. In general, Developers Console projects are a way of managing authorization, APIs being used, billing, quotas and other settings for an application. For Apps Script projects, the Developers Console project is primarily used to manage authorization and Advanced services.
In most cases, you do not need to adjust a script's Developers Console project, as Apps Script handles most necessary configurations automatically. However, in some instances you may want to make setting adjustments, such as turning on an Advanced service.
To access an Apps Script's Developers Console project, do the following:
- Open the script in the Apps Script editor.
- Select Resources > Developers Console Project.
- In the dialog that opens, click the top link, which will be something like [Script Name] - api-project-123456789012.
This will take you directly to the Developers Console project that the script is currently using. You may be asked to accept a terms of service agreement if you have not done so already.
Using a different Google Developers Console project
It is possible to switch a script so that it uses a different, existing Developers Console project. This may be valuable if you want to consolidate a script with another existing application, so that they share the same authorization and other settings. This feature is most commonly used to bundle an add-on with a Google Apps Marketplace app, or ensure a script shares a project with an app calling it with the Execution API. Moving a script to another Developers Console project causes the script's original developer console project to be deleted.
To change a script's Developers Console project over to another, existing Developers Console project and delete the original project the script is using, follow these steps:
- Open the Google Developers Console.
- In the upper-right corner, there is a drop down menu. The label of this menu may be Select a project, Go to a project, or be the name of an existing project you recently opened in the console. Select the menu, then select Manage all projects.
- Locate the project you want the script to be associated with and select it.
- In the upper-right corner, click the three-dots icon, and select Project information.
- Locate and copy the Project Number. You will need this later.
- In the Apps Script editor, open the script whose Developer Console project you want to delete and replace.
- Click Resources > Developers Console Project.
- Paste the project number you copied into the text field, then click Set Project.
- A warning screen will explain the effects of changing the Developers Console project. Read the notice carefully, then enter the old project number from the last sentence of the warning (in bold) into the text field and click Confirm.
There may be cases in which you want multiple scripts to share the same Google Developers Console project. You can't select an existing console project when create a new script -- new scripts always create a new console project. Since these default console projects are hidden, they cannot be used as the destination projects for a switch. If you see a "Project does not exist or you need edit access to it" error when attempting to switch a script's project, that usually means you are attempting to move it to one of these default projects.
To get around this restriction, create a new, blank Developer Console project, and use the steps above to add each script to that.