IssueTracker

Additional Info For the logs listed above:

Execute the app as:

Me (*****@gmail.com)

Who has access to the app:

Anyone, even anonymous

Runtime = V8

Hello there,

In order to able to investigate this accordingly, I will be needing more information.

1. Can you share a short snippet which reliably reproduces the issue?

2. Are you the owner of the script or does anyone else have access to it?

3. Which scopes does your script require? (Overview > Project OAuth Scopes in the new editor)

4. Does this happen when using the legacy editor or you noticed this behavior only when using the new editor?

Hi, thanks. Considering I have several web apps that have done this, I will continue to use the one that I shared the logs for above.

Can you share a short snippet which reliably reproduces the issue?

A. doGet(e) {UrlFetchApp.fetch("https://www.google.com")} should suffice as a simplistic version of what mine is doing. Although I will admit, I'm slightly confused. The code isn't changing, and I'm not entirely sure how a code snippet can reproduce authentication suddenly dropping while I am sleeping, and then waking to a flurry of Authentications required in my inbox.

Are you the owner of the script or does anyone else have access to it?

A. Yes I am the owner. I'm not sure if you mean because it is published, in that case technically yes - or if you mean their email has been added as a collaborator, in that case no, as I am the only user in that regard.

Which scopes does your script require? (Overview > Project OAuth Scopes in the new editor)

A. https://www.googleapis.com/auth/script.external_request

Does this happen when using the legacy editor or you noticed this behavior only when using the new editor?

A. Unfortunately I can't say with certainty that I never used the new editor while accessing this script. Other scripts that have had this same issue I do know that I have switched back and forth between the two. However, I am fairly certain I have not published via the new editor for this particular script. It is still published under the old editor. I will note though, that I have never dealt with this issue in such a recurrence until the new editor was released around the time of the first log timestamp (at least that is when it showed for me, I'm sure it was available to other users/test groups before).

-Something I forgot to mention, though I don't know if it makes a difference. I primarily use Clasp via Visual Studio Code. I don't know if perhaps there is anything conflicting happening between the new editor when pull/pushing (aside from the obvious 'the manifest has changed' alert when attempting to push new code, in which case the push is stopped - code repulled, then changes are made and pushed)

Annnnnnnnnnnnd it just happened again last night randomly. This is getting really old really fast. Thankfully I have added a simple reAuth function on a trigger that fails every time to let me know exactly when this starts. Here are the screenshots. And just as a reminder, I am doing absolutely nothing on my end to change anything. So this is a server issue.

It looks like you also have a trigger associated with this - how often is this trigger running? Are you getting the same results when running the function without the trigger?

I added the trigger(s) purely because there is no other way to alert myself via Apps script of this issue. I added this function: function reAuth() {} (just an empty function) to all of my web app scripts right after creating this bug/issue. This way I know exactly when it happens. I have that specific function/trigger running every 10 minutes so that it will alert me when it fails and send me emails immediately so I can reauthorize the scripts. Unfortunately, this always happens during the middle of the night when I am sleeping.

The two screenshots are from 2 separate scripts. I snagged a screenshot from the logs also which matches, although looks like it's 1 minute earlier than the trigger. So 1 script started failing around 1:15am and the other at 2:49am

The "Authorization is required" isn't even recognized as an error in stackdriver either.. it's only at a .info level.. so you can't create an alert for it. Your application just stops working until you suddenly realize it hasn't been running for some time, hence the newly added triggers. Please note the trigger has nothing to do with the applications, they are purely a stop-gap to alert me to this issue because there is nothing I can do to fix it from my end. It is frustrating.

Edit: I missed the last part of your question: RE Are you getting the same results when running the function without the trigger?: After I reauthorize, yes, no issues. The trigger and rest of the web app runs fine.. until the server cuts the authorization again that is. Then everything fails.

Script #3 just went off. Had to reauth.

Thank you for all the details.

I have forwarded them internally.

Best regards

Thank you

We can't reproduce your issue without a some information regarding your script and account. This is a public forum so it isn't the place to share it here. Please contact Google Workspace support and let them know about this issue, and share with them a scriptId and permissions to view it.

Kind regards,

Alright thanks.

Please refer to this issue: https://issuetracker.google.com/177921123 when you reach out to support in order for them to find this case.

Kind regards,

When I contacted support, they said they are unable to assist consumer accounts, only Google Workspace accounts.

Hi,

As possible causes of the issue have you checked Refresh token expiration?

The user has revoked your app's access.

The refresh token has not been used for six months.

The user changed passwords and the refresh token contains Gmail scopes.

The user account has exceeded a maximum number of granted (live) refresh tokens.

Is the issue still happening?

Regards.

Hi,

Yes, this still happens. It is random rather than constant.

A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.

After reading this it sounds plausible, except it's not a set period like every 7 days it happens, but more random in nature.

I have found that there is some kind of issue with GCP and auth scopes. I have since removed the projects from a standard GCP and changed to a default Apps Script managed project (for the ones that I could and don't need as verbose logging) and they have stopped having authentication issues. The ones still connected to the standard GCP projects will still randomly lose their authentication for the scopes in the projects and I have to manually re-authenticate.

The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.

I'm not sure if these match the current scenarios in the projects. They don't really fit the current state of the projects.

By removing the GCP projects and copying the existing projects to a new Apps Script project, it has helped for the several that were having issues. The others still using the standard GCP project still have issues. The last time it happened was 3 days ago.

I will see if I can notice a pattern that matches with the 7 day token refresh scenario.

Hello,

Thank you for the information.

Please let us know if the issue has a pattern with the token refresh.

Regards.

It looks like it happened again after 7 days so that may in fact be the case. However, in the past, it seemed more random as I don't see logs every 7 days.

But if this is the case where the token is expiring every 7 days, how do I refresh it automatically without having to do so manually? Some of these applications/web apps are being used by myself only, but if I were to "publish" them into production instead of "testing" I would have to go through the entire verification process which is overkill for what I need. (while still retaining the web app functionality)

Thanks

?

Hello,

Apologies for the delay!

Does it also happens with new scripts created and then linked to a GCP project? Can you try it?

Also, can you provide the script and the how is the trigger set up as well as how are you publishing the scripts in order to reproduce it as you have it?

Thank you!

Hi

I created another GCP project 9 days ago and tried replacing the previous project with the new one at that time to see if it would make a difference. But I still received errors 2 days ago:

4/12/21 4:16 PM reAuth Authorization is required to perform that action. time-based 4/12/21 4:16 PM

The trigger is just a normal time trigger that runs every 10 minutes. I run an empty function: function reAuth() {} for the purpose of just making sure the trigger runs. When the project scopes lose their authorization, the trigger automatically fails so I know exactly when I have to manually reauth the scopes because it sends me an email. Unfortunately Authorization is required to perform that action. is not actually considered an error in the stacktrace logs. It is only classified as a severity: "NOTICE" so this is the only way for me to be able to check when this happens. (please consider making the severity an error, not a notice in the logs)

I'm pretty sure I've attempted recreating the apps script projects also, but just to be sure I will do so now for 1 project to test. (The same one that I recreated the GCP project for as that made no difference)

The application is published as a webapp (this issue only affects published web apps from what I can tell) - Executed as myself with Anyone for access.

I have made a copy of the project and configured everything the same as the original. I'll have to wait 7 days to see if it is affected by the authentication scenario and will report back.

Hello,

This is an update to my last comment.

The new Apps Script project made no difference. And as stated previously, using a new GCP made no difference. I received a trigger error just now from not only the new Apps Script project but the old at basically the same time.

Results of the duplicated project as a test: Auth Scopes dropped in 5 days - so the 7-day requirement might not be anything important. I have noticed it tends to happen on Sunday/Monday. I haven't opened the project, made any changes, or anything since it was created. I simply copied the original, published it as a web app just like the other, then created an empty function to run with the trigger to know when it fails and loses scopes just like the original. (Also connected to the same GCP project as the original, but as stated before, this is a new GCP project also.) Like clockwork, it failed.

Please look into this. I've done everything that I can do from a user perspective that I can think of.

Hello and thanks for getting back to us with the results of your test. In parallel I have had a few tests running too, but in mine I can't seem to reproduce your error.

At this point I would need you to clarify a few things:

It seems that your Apps Script project may contain other functions. You say you "copied" the project, how did you do this exactly?

Reviewing this thread, namely comment #3, calling ScriptApp.getOAuthToken() may be related. Do you have a function in your project that contains this or something similar?

I just want to confirm that you are saying that you are creating a completely blank project, adding a simple function that makes a call to UrlFetchapp, linking it to a non-default GCP project, and after 7 days have it present this error?

The best thing at this stage would be for you to provide clear and detailed step-by-step instructions on how to reproduce this. Then we will test that on our end. If we can't reproduce it, there is nothing we can do. These instructions would need to look something like this:

1. Start a new blank Apps Script project.
2. Paste this following code (insert ALL the code here)
3. Initialize a new GCP project and take note of the project number.
4. Link the Apps Script Project to the GCP project.
5. Set up a time based trigger to trigger X function every 10 minutes.

Its best if you provide this in this fool proof manner because it takes 7 days for the results to come in, its best we are 100% clear on the steps before starting the reproduction. Additionally, up until now we have not been able to reproduce it, so there must be something we are missing.

Thank you for your patience.

It seems that your Apps Script project may contain other functions. You say you "copied" the project, how did you do this exactly?

-I went to the overview tab in the Apps Script editor and clicked on Make a copy

Reviewing this thread, namely comment #3, calling ScriptApp.getOAuthToken() may be related. Do you have a function in your project that contains this or something similar?

-No I don't use that in any of my functions. I do use an OAuth2 library, however, it does not use ScriptApp.getOAuthToken() -Note that some of my other published web app projects (that are connected to a GCP) fail without using that library.

The best thing at this stage would be for you to provide clear and detailed step-by-step instructions on how to reproduce this. Then we will test that on our end. If we can't reproduce it, there is nothing we can do. These instructions would need to look something like this:

Start a new blank Apps Script project.
Paste this following code (insert ALL the code here)
Initialize a new GCP project and take note of the project number.
Link the Apps Script Project to the GCP project.
Set up a time-based trigger to trigger X function every 10 minutes.

-I did these steps last time with the exception of 2 items. I used the Make a copy option instead of copy/paste code. I made a new GCP project for this application a few weeks ago to see if it would change anything (but it hasn't) so the new duplicate test project that I just recently created was connected to the new GCP project.

So what I'll do now is create brand new projects (apps + GCP) with 0 code except for 2 functions which will mimic what my application is doing (in pseudo-code), but should allow for simple sharing/diagnosing/troubleshooting.

/*
New non-default GCP:
Project name:
Auth Scope Fail Test
Project ID:
auth-scope-fail-test
Project number:
943197191524

New Apps Script project: https://script.google.com/d/18NGXgOjuv9UKf_O46aGy_x3R-frzO0tWmqrm2IuD57zC3g98pI9NGyW6/edit?usp=sharing
Published as:
Web App
Execute as:
Myself
Access Allowed:
Anyone
*/

Function 1: function call() { UrlFetchApp.fetch("https://www.google.com") } 
Function 2: function reAuth() {} //connected to trigger that runs every 10 minutes

This will give me the external scope requirement which is what most of the projects that fail have included (usually the only scope in the project, but not always) - The link for the new project included should be viewable

The smoking gun in my opinion is the connection between the non-default GCP and Apps script project set to "Testing" in the OAuth consent screen. Here are the simplified scenarios explanations based on my current projects:

All Published Web Apps:
Apps Script + Connected to non-default GCP Project + OAuth Consent set to Testing = Fail
Apps Script + Connected to non-default GCP Project + OAuth Consent set to Published = No issues
Apps Script + Not connected to non-default GCP Project (Managed by Apps Script) = No issues

Once I see the trigger fail I'll send another update

Thank you, so the final instructions for the test I have set up are:

1. Start a new blank Apps Script project.
2. Paste this following code

function call() { UrlFetchApp.fetch("https://www.google.com") }
function reAuth() {} //connected to trigger that runs every 10 minutes

3. Initialize a new GCP project and take note of the project number.
4. Set up the OAuth consent screen without any scopes. Set it to "External" and "Testing" and add yourself as testing user.
5. Link the Apps Script Project to the GCP project.
6. Set up a time based trigger to trigger reAuth function every 10 minutes. This will prompt a script authorization.

Please confirm these steps, especially the part about setting up the OAuth screen with no scopes.

Just to ensure that we are on the same page. This behavior will need to reproduce on my account, not yours, for us to be able to move forward. Therefore, if there are any details that have been missed in these reproduction steps, please include them as soon as possible.

I think the only difference between what you did and I did was I manually added the external API scope to the OAuth consent screen for this particular test. Everything else is as you mentioned. However, I'm not sure that the scopes included actually make a difference. One project failed just recently 4/19/21 9:10 AM log Authorization is required to perform that action. time-based 4/19/21 9:10 AM - this one has no scopes included in the OAuth screen (it does use external request scope but just not added to the scopes on the consent screen), but everything else matches a similar setup. I think it has more to do with the "Testing" setting.

Just to ensure that we are on the same page. This behavior will need to reproduce on my account, not yours, for us to be able to move forward.

-Great. I'm probably screwed then. This isn't exactly something I see 100s of people +1'ing the issue.

Thanks

Which scope specifically are you adding manually? The "external request scope"? Can you also copy and paste the Apps Script manifest here so I can take a look?

Yes, that's correct.

Scope: https://www.googleapis.com/auth/script.external_request

This is the link for the project: https://script.google.com/d/18NGXgOjuv9UKf_O46aGy_x3R-frzO0tWmqrm2IuD57zC3g98pI9NGyW6/edit?usp=sharing

Manifest:

{
  "timeZone": "America/New_York",
  "dependencies": {},
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8",
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "ANYONE_ANONYMOUS"
  }
}

I just noticed that there's no mention of deployment as a web app in your description so I just wanted to make sure you deploy it as a web app as well. This issue doesn't affect non-web app projects from what I can tell.

I am going to create another test setup that has 0 scopes included in the OAuth consent screen. I don't think it will make a difference, but why not. (Mainly because I have projects already in place that do not have scopes included in the OAuth consent screen but still fail - in "Testing" mode of course)

Second Test - 0 OAuth Scopes included in consent screen: https://script.google.com/d/1NCZjVqScevcyCewWEMDIKKq2kCGTVeL7uGf9FSPiSFhGRY0K9tOHPBhh/edit?usp=sharing

/*
New non-default GCP:
Project name
Auth Scope Failed Test 2
Project ID
auth-scope-failed-test-2
Project number
451301610874

New Apps Script project: https://script.google.com/d/1NCZjVqScevcyCewWEMDIKKq2kCGTVeL7uGf9FSPiSFhGRY0K9tOHPBhh/edit?usp=sharing
Published as:
Web App
Execute as:
Myself
Access Allowed:
Anyone
*/

function call() { UrlFetchApp.fetch("https://www.google.com") } 
function reAuth() {} //connected to trigger that runs every 10 minutes

Manifest:

{
  "timeZone": "America/New_York",
  "dependencies": {},
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8",
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "ANYONE_ANONYMOUS"
  }
}

So final repro steps are:

1. Start a new blank Apps Script project. (Using the new IDE)
2. Paste this following code

function call() { UrlFetchApp.fetch("https://www.google.com") }
function reAuth() {} //connected to trigger that runs every 10 minutes

3. Run call and authorize.
4. Deploy as web app, set to execute as "myself" and accessible by "anyone"
5. Initialize a new GCP project and take note of the project number.
6. Set up the OAuth consent screen with the scope https://www.googleapis.com/auth/script.external_request. Set it to "External" and "Testing" and add yourself as testing user.
7. Link the Apps Script Project to the GCP project.
8. Set up a time based trigger to trigger reAuth function every 10 minutes.

--

I suspect not, but do you think the order of these operations is significant here?

A thought that occurs to me is that setting the OAuth scopes explicitly in the manifest might affect the behavior:

"oauthScopes": [
      "https://www.googleapis.com/auth/script.external_request",
    ],

Since you haven't done this, I won't do it for my tests, but maybe you can try on one of your existing projects to see if anything different happens.

With that said and the tests set up, reviewing the documentation, it reads:

Authorizations by a test user will expire seven days from the time of consent.

Source

So I'm not sure we should expect anything different from these tests.

Also re-reading this thread, in your first comment you said that this was affecting projects that already published. Though I understand that you fixed the original projects that were having issues by un-linking the GCP projects.

A possible fix would be filling the scopes manually in the manifest for these types of issues. This is because Apps Script tries to infer the scopes needed at runtime, and sometimes this can result in Apps Script trying to gain more permissive scope than what is authorized.

See Setting Explicit Scopes

However, token expiry in around 7 days is to be expected for projects in "testing" state. I will keep the tests running just in case it expires much sooner or anything else odd takes place.

Welp - it's as you pointed out. The expiration is due to the testing state. I don't recall seeing any notifications about how these changes to the OAuth flow would affect existing projects back in January when it first started happening, but it's nice to have the documentation now to see that this is the case.

I was under the impression that changing the status to published would revoke all scopes until the Google verification was in place. But that's not the case it seems. I can still use/publish the apps under my account without going through the verification process (which is overkill for what I need) which is the goal.

Thanks for the link and looking into it. You can close this.

I have had similar issue and at least it is now clear why this is happening, thank you! I wonder if it is possible to make a feature that would allow the owner of a GCP script to be a permanent tester (without a need to reauthorize it each 7 days)? Just so it is possible to make and run small script projects intended for personal use.

Yeah, that is what I was expecting in a way. I'm surprised I have to add myself as a tester.. considering I am the owner of the GCP project. It should be baked in.

Thank you for the confirmations, this issue will now be closed as my test have also run as expected.

Regarding the request to make the creator a permanent tester, it would be in the best interest of the feature request to make a new issue as a feature request, and provide as much detail, context and justification as possible. 7 day expiration is a security feature so it can become complex quite quickly.

Thank you again.