Fixed
Status Update
Comments
jp...@google.com <jp...@google.com> #2
Kk, got a more contained example of the issue using a very small add-on.
source:
https://script.google.com/d/1o3AvP1zRrx7WnDEx_fV_IhS2fc3QstuKHvFaBsqjcffqxdhLNjC7j62S/edit?usp=sharing
add-on listing:
https://chrome.google.com/webstore/detail/dcpikpbagjcipkfmacefilfbkdjlfjmd
Because I've made the add-on "unlisted" there are slightly different reproduction steps:
* Steps 1-4 are the same as in my original post
5. In the Incognito window that you're testing this in, open the following link
https://chrome.google.com/webstore/detail/auth-issue-tester/dcpikpbagjcipkfmacefilfbkdjlfjmd?authuser=1
The "authouser=1" query parameter is very important in the above link as otherwise the add-on will be installed for the "default" account and the issue won't express.
6. Click the "+ Free" button on the above linked page to install the add-on
7. In the new Sheet you will be brought to after clicking "+ Free", wait a few seconds for prompt to appear. Click "continue" and then authorize the add-on
8. Open the Dev console
9. Go to "Add-Ons" => "Auth Issue Tester" => "Open Sidebar"
10. Note the error printed to the console and inserted into the sidebar
Demo of the above listed steps 5-10:https://cl.ly/0p0v080F2j1s
source:
add-on listing:
Because I've made the add-on "unlisted" there are slightly different reproduction steps:
* Steps 1-4 are the same as in my original post
5. In the Incognito window that you're testing this in, open the following link
The "authouser=1" query parameter is very important in the above link as otherwise the add-on will be installed for the "default" account and the issue won't express.
6. Click the "+ Free" button on the above linked page to install the add-on
7. In the new Sheet you will be brought to after clicking "+ Free", wait a few seconds for prompt to appear. Click "continue" and then authorize the add-on
8. Open the Dev console
9. Go to "Add-Ons" => "Auth Issue Tester" => "Open Sidebar"
10. Note the error printed to the console and inserted into the sidebar
Demo of the above listed steps 5-10:
bl...@google.com <bl...@google.com> #3
Thank you for your report. The Apps Script team is investigating.
ma...@toho.ne.jp <ma...@toho.ne.jp> #4
ph...@airbus.com <ph...@airbus.com> #5
I was the person who originally reported this issue to Streak.
tk...@gmail.com <tk...@gmail.com> #6
I am facing similar issue. Getting error "You do not have permission to call showSidebar" on Opening the file (Docs, Sheets etc..)
Since yesterday, I am getting an exception when calling showSidebar() function with in onOpen().
I am building custom menu onOpen and calling showSidebar() function with in onOpen(). I want run check a few things in a Google Sheet every time the file is open and display an alert and sidebar if certain condition is not met.
The functionality was working perfectly, until yesterday!!
Below is the error that I am getting onOpen()
"You do not have permission to call showSidebar"
I have been using the same script from beginning of this year and never had this issue. I started seeing it since yesterday. Just wondering recent changes to OAuth scope to include " container.ui " is causing the issue.
Since yesterday, I am getting an exception when calling showSidebar() function with in onOpen().
I am building custom menu onOpen and calling showSidebar() function with in onOpen(). I want run check a few things in a Google Sheet every time the file is open and display an alert and sidebar if certain condition is not met.
The functionality was working perfectly, until yesterday!!
Below is the error that I am getting onOpen()
"You do not have permission to call showSidebar"
I have been using the same script from beginning of this year and never had this issue. I started seeing it since yesterday. Just wondering recent changes to OAuth scope to include " container.ui " is causing the issue.
al...@pwc.com <al...@pwc.com> #7 Restricted+
Restricted+
Comment has been deleted.
ta...@iot.croix-rouge.fr <ta...@iot.croix-rouge.fr> #8
Comment has been deleted.
ta...@iot.croix-rouge.fr <ta...@iot.croix-rouge.fr> #9
Comment has been deleted.
ru...@croix-rouge.fr <ru...@croix-rouge.fr> #10
Folks how can we get this escalated for an action by Google team ? Its been close to 15 days since the issue started and there has been no action!!
pi...@airbus.com <pi...@airbus.com> #11
Thank you for your reports. The issue originally reported is due to recent improvements in Sheets' ability to handle multiple logged in accounts. These improvements expose limitations in Apps Script's ability to do the same. In particular, users may experience issues if they (1) are logged into more than one gmail.com account or more than one account belonging to the same G Suite domain, (2) have selected an account other than the default account while using Docs, Sheets, Slides, or Forms, and (3) use add-ons or the script editor.
st...@revevol.eu <st...@revevol.eu> #12
Thanks for the clarification of the issue - that matches what we've been seeing. Are you all actively working on a fix or is there a workaround? This is a pretty frustrating experience for our users.
se...@inforisme.fr <se...@inforisme.fr> #13
We're seeing the same. In addition, Session.getEffectiveUser().getEmail() is no longer reliable, if you're logged in with multiple gmail accounts it always returns the first one. Quite a serious problem, please fix this urgently.
st...@addonsforgapps.com <st...@addonsforgapps.com> #14
We have the same issue which is causing our Supermetrics Data Studio community connector to throw errors.
je...@airbus.com <je...@airbus.com> #15
We have the same issue which is causing all of our google sheet queries to break. Its broken our entire data pull that we use with DOMO.
ia...@gmail.com <ia...@gmail.com> #16
I can confirm that this issue exists for the Search Analytics for Sheets add-on as well.
jb...@wayfair.com <jb...@wayfair.com> #17
I have the same issue
be...@galec.leclerc <be...@galec.leclerc> #18
Same issue here, all of my reports are down.
ru...@croix-rouge.fr <ru...@croix-rouge.fr> #19
I have the same issue
oh...@gmail.com <oh...@gmail.com> #20
We have a very urgent problem. All our reports in Supermetrics with data from Analytics are failing. We get the message "Error: 403 The caller does not have permission (view ID: 12511297)" and the "view ID" number in the error message keeps changing. We have tried using the "Refresh account list " and sometimes it help, but when we run it again we get the same message "Error: 403 The caller does not have permission (view ID"
ni...@apps4gs.com <ni...@apps4gs.com> #21
Same problem - all our dashboards on data pulled by Supermetrics are broken - please fix!
ga...@gmail.com <ga...@gmail.com> #22
Any news on this?
ad...@tcoccolo.com.ar <ad...@tcoccolo.com.ar> #23
My script is also affected. Any news?
bl...@lamar.com <bl...@lamar.com> #24
Any news Google?
su...@oralpath.ca <su...@oralpath.ca> #25
Any news on this?
rj...@gmail.com <rj...@gmail.com> #26
Any new info?
rs...@gmail.com <rs...@gmail.com> #27
Any update regard this issue .
dr...@gmail.com <dr...@gmail.com> #28
Ya it's odd. I have been experiencing issues for awhile on this and never knew about this forum to track issues. So cool Goog!
sa...@gmail.com <sa...@gmail.com> #29
I'm starting to think Google team also don't know about this forum :/
ph...@lepechdandre.fr <ph...@lepechdandre.fr> #30
I wrote an article explaining how we are currently dealing with this issue in add-ons like Yet Another Mail Merge:
https://sites.google.com/site/scriptsexamples/home/announcements/multiple-accounts-issue-with-google-apps-script
Note that there are 2 cases to handle. The "authorization is required" error is thrown when the other account has not granted permissions to your script. But if both accounts have granted permissions, then the script might run well with the permissions of the wrong account (which might be worse: eg: emails being sent from the wrong account).
Note that there are 2 cases to handle. The "authorization is required" error is thrown when the other account has not granted permissions to your script. But if both accounts have granted permissions, then the script might run well with the permissions of the wrong account (which might be worse: eg: emails being sent from the wrong account).
ti...@gmail.com <ti...@gmail.com> #31
no response Google? I'm getting user emails about this all the time.
ma...@gruppoasa.com <ma...@gruppoasa.com> #32
This issue already obtained 90+ stars, why Google isn't taking any action on this?
ab...@gmail.com <ab...@gmail.com> #33
Are you realy surprized with it? I'm not :)
se...@supermetrics.com <se...@supermetrics.com> #34
A user can be logged into multiple Google accounts in the browser. But what account is your add-on or Apps Script code using? If your add-on or Apps Script code tries to use an account that it is not authorized to use, then there will be an authorization error.
How do you test for that?
If you want to "manually" verify that this is a problem, you can test for whether this is related to the multiple accounts issue, by either having the person log out of all accounts, and then log back into the account that installed the add-on, or have them open up the Chrome browser in incognito mode, and log into the account that installed the add-on.
The problem occurs when a google.script.run.FUNCTION() call is made from the HTML after the HTML in your Web App, sidebar, dialog box has loaded.
When the HTML first loads, you must run a scriptlet, which runs on the server, and get the effective user. That gives you the account name that the Apps Script code is running under. Then, as soon as the HTML loads, you immediately make a google.script.run.function() call to the server and get the user account name again. Then if the two are not the same, there is a problem.
function getAccountName_() {
//Put user email into html when it loads for determining whether user is the authorized user
return Session.getEffectiveUser().getEmail();
}
<input id="idAccountOfEffectiveUsr" type="text" style="display:none" <?!= getAccountName_() ?>/>
<script language="javascript">
//console.log('it ran on load one')
window.onload = function() {
google.script.run
.withFailureHandler(failedAcctTest)
.hazAcctConflict()
//console.log('it ran on load two')
//AlanWells.shwFirstTimeHlp();
};
window.failedAcctTest = function(rtrn) {
var usrWhoLoaded = document.getElementById('idAccountOfEffectiveUsr').value;
if (usrWhoLoaded !== rtrn) {
showErrMsg('The Add-on loaded under the account: \n\n' + usrWhoLoaded + '\n\nBut you are also logged into ' +
'account: ' + rtrn + "\n\nYou are logged into multiple accounts which has caused an authorization error. \n\n" +
"You must either log out of all accounts, and log back into the account that installed the add-on; or open " +
"an incognito window, log in and use the add-on from that window");
}
}
</script>
How do you test for that?
If you want to "manually" verify that this is a problem, you can test for whether this is related to the multiple accounts issue, by either having the person log out of all accounts, and then log back into the account that installed the add-on, or have them open up the Chrome browser in incognito mode, and log into the account that installed the add-on.
The problem occurs when a google.script.run.FUNCTION() call is made from the HTML after the HTML in your Web App, sidebar, dialog box has loaded.
When the HTML first loads, you must run a scriptlet, which runs on the server, and get the effective user. That gives you the account name that the Apps Script code is running under. Then, as soon as the HTML loads, you immediately make a google.script.run.function() call to the server and get the user account name again. Then if the two are not the same, there is a problem.
function getAccountName_() {
//Put user email into html when it loads for determining whether user is the authorized user
return Session.getEffectiveUser().getEmail();
}
<input id="idAccountOfEffectiveUsr" type="text" style="display:none" <?!= getAccountName_() ?>/>
<script language="javascript">
//console.log('it ran on load one')
window.onload = function() {
google.script.run
.withFailureHandler(failedAcctTest)
.hazAcctConflict()
//console.log('it ran on load two')
//AlanWells.shwFirstTimeHlp();
};
window.failedAcctTest = function(rtrn) {
var usrWhoLoaded = document.getElementById('idAccountOfEffectiveUsr').value;
if (usrWhoLoaded !== rtrn) {
showErrMsg('The Add-on loaded under the account: \n\n' + usrWhoLoaded + '\n\nBut you are also logged into ' +
'account: ' + rtrn + "\n\nYou are logged into multiple accounts which has caused an authorization error. \n\n" +
"You must either log out of all accounts, and log back into the account that installed the add-on; or open " +
"an incognito window, log in and use the add-on from that window");
}
}
</script>
mb...@slido.com <mb...@slido.com> #35
Issue resolved by opening form/data director in Incognito window.
jp...@google.com <jp...@google.com> #36
I can confirm the issue is not reproduced with Incognito window, however, this does not really mean it is resolved. Writing this in order to prevent this issue to be accidentally closed.
ja...@cascade-care.com <ja...@cascade-care.com> #37
+1 to "pa...@gmail.com"
Using a given Add-on in an Incognito window is an effective workaround for this issue as one usually only signs into a single Google account when using an Incognito window, which fundamentally sidesteps this issue.
Using an Incognito window effectively circumvents this issue, but is not a "solution" or "fix".
Using a given Add-on in an Incognito window is an effective workaround for this issue as one usually only signs into a single Google account when using an Incognito window, which fundamentally sidesteps this issue.
Using an Incognito window effectively circumvents this issue, but is not a "solution" or "fix".
yt...@accon.services <yt...@accon.services> #38
Are there any updates on this? I can see the last question to the team was asked on 22 Nov 2017 and was left without a reply. How come is priority 2 if it is a blocker and severity 2 when nowadays almost everyone is logged in into multiple accounts? Anyone from the team, please let us know if you are working on this and what is the status, our customers suffer.
co...@gmail.com <co...@gmail.com> #39
Any updates on this?
Posting mainly for the sake of not letting this ticket go completely inactive.
Posting mainly for the sake of not letting this ticket go completely inactive.
ru...@croix-rouge.fr <ru...@croix-rouge.fr> #40
I have the same issue in my add-on and the 'Incognito window' method doesn't work for me. But I fixed in another way.
Since I'm the developer of the add-on, I just remove the manifest file attached to the add-on, and rerun it. After authorizing with new permissions, it works.
Since I'm the developer of the add-on, I just remove the manifest file attached to the add-on, and rerun it. After authorizing with new permissions, it works.
me...@gmail.com <me...@gmail.com> #41
Very disgusting. Still no action being taken.
am...@jefferson.kyschools.us <am...@jefferson.kyschools.us> #42
I have issues with script errors, pls fix it .!!!
ph...@lepechdandre.fr <ph...@lepechdandre.fr> #43
'Incognito window' method doesn't work for me
nb...@slido.com <nb...@slido.com> #44
+1. Really inconvenient for users and kind of ridiculous. What sane developer would try to write plugins for Google Forms when the flagship example doesn't teach how to handle common use cases?
an...@bbva.com <an...@bbva.com> #45
Still no action?
qi...@gmail.com <qi...@gmail.com> #46
Tired of constantly needing to explain to your users why they are getting authorization errors, when they are logged into multiple accounts?
Implement some code to automatically explain it to them, so you won't need to.
Code posted at GitHub
https://github.com/Blueprinter/Authorization-Error-Multiple-Accounts
Implement some code to automatically explain it to them, so you won't need to.
Code posted at GitHub
di...@bbva.com <di...@bbva.com> #47
Nine months is way too much time for this issue to be with Status:New and no Assignee
This issue scares away most of new users using multiple accounts and consume a daily quota of time and effort from the developers
Google
Could you please, fix this issue or at least tell us you are doing something about it?
Thanks
This issue scares away most of new users using multiple accounts and consume a daily quota of time and effort from the developers
Could you please, fix this issue or at least tell us you are doing something about it?
Thanks
ce...@davivienda.com <ce...@davivienda.com> #48
supporting multiple accounts would be rather proper, compared to demanding workarounds; logged-in accounts have an index; that's also where the 0, 1, etc. in the G+ urls comes from. would assume, that in this case it's the account with index 1 trying to access - while the script wrongfully assumes account at index 0... logging out both accounts and the signing in in different order would also change their index... just as using an incognito window would use the account at index 0.
vl...@fordham.edu <vl...@fordham.edu> #49
Will this ever be fixed?
vi...@biomass-concept.com <vi...@biomass-concept.com> #50
🎂 Celebrating the First Anniversary of this Issue
Still strong as New and Unassigned
Still strong as New and Unassigned
kr...@highgradeusa.com <kr...@highgradeusa.com> #51
🎂🎉🎁
Happy Birthday authorization issue!
It's been amazing watching how little you've grown or changed.
Happy Birthday authorization issue!
It's been amazing watching how little you've grown or changed.
il...@gmail.com <il...@gmail.com> #52
Congrats! Because it's not important it shouldn't been done! :D
er...@banestes.com.br <er...@banestes.com.br> #53
Happy anniversary!
gp...@banestes.com.br <gp...@banestes.com.br> #54
Happy Birthday! ..but nobody came to the party?.. I don't think any of the developers like you much!
on a related issue..
does anyone have a "best practice" for the following use case:
* a google apps script is deployed as a web app (ex: "https://script.google.com/macros/s/xxx/exec ")
* the script is hosted on another domain (ex: "https://myapp.com ") and contained within an iframe element
* when a visitor loads the iframe but is not presently already logged into any Google account, the iframe contains an empty document
* console shows the error: "Refused to display 'https://accounts.google.com/ServiceLogin?passive=xxx&continue=https://script.google.com/macros/s/xxx/exec&followup=https://script.google.com/macros/s/xxx/exec ' in a frame because it set 'X-Frame-Options' to 'deny'."
* this is in contrast to what happens when the web app is loaded directly (outside of any iframe) and the window automatically redirects to a login screen
I tried using Google Sign-in for Websites, obtaining a clientID for the custom domain:
* when the visitor comes to the domain and is not presently already logged into any Google account, this will allow the visitor to log in (ex: account #0).. after which, the content in the iframe can load properly
* when the visitor is already logged into one single Google account (ie: #0), the visitor would still be required to click the "log in" button.. and then select the account (ie: #0).. in order to authorize the site
* when the visitor is already logged into multiple Google accounts (ie: #0, #1, #2, ...), the visitor would still be required to click the "log in" button.. and then select an account from a list.. however regardless of which account is selected.. the content that loads in the iframe will always see the "active" account (ie: #0)
I'm still trying to figure out an adequate workaround for this situation.. and haven't found any that would be satisfactory to visitors..
Google: please fix this issue on the backend.. and add support to Google Apps Script for selecting between multiple active user accounts.
Also, it would be VERY helpful if web apps loaded within an iframe could follow the same authorization workflow as occurs outside of an iframe.. which is to manage the login process when needed.
Thank you.. hope to see you again before next year's anniversary!
on a related issue..
does anyone have a "best practice" for the following use case:
* a google apps script is deployed as a web app (ex: "
* the script is hosted on another domain (ex: "
* when a visitor loads the iframe but is not presently already logged into any Google account, the iframe contains an empty document
* console shows the error: "Refused to display '
* this is in contrast to what happens when the web app is loaded directly (outside of any iframe) and the window automatically redirects to a login screen
I tried using Google Sign-in for Websites, obtaining a clientID for the custom domain:
* when the visitor comes to the domain and is not presently already logged into any Google account, this will allow the visitor to log in (ex: account #0).. after which, the content in the iframe can load properly
* when the visitor is already logged into one single Google account (ie: #0), the visitor would still be required to click the "log in" button.. and then select the account (ie: #0).. in order to authorize the site
* when the visitor is already logged into multiple Google accounts (ie: #0, #1, #2, ...), the visitor would still be required to click the "log in" button.. and then select an account from a list.. however regardless of which account is selected.. the content that loads in the iframe will always see the "active" account (ie: #0)
I'm still trying to figure out an adequate workaround for this situation.. and haven't found any that would be satisfactory to visitors..
Google: please fix this issue on the backend.. and add support to Google Apps Script for selecting between multiple active user accounts.
Also, it would be VERY helpful if web apps loaded within an iframe could follow the same authorization workflow as occurs outside of an iframe.. which is to manage the login process when needed.
Thank you.. hope to see you again before next year's anniversary!
rb...@curativetalent.com <rb...@curativetalent.com> #55
Happy Belated Birthday!
se...@gmail.com <se...@gmail.com> #56
Having the same problem here!
ab...@cps.edu <ab...@cps.edu> #57
Why no action is taken?
ma...@inspiredaccounting.co.uk <ma...@inspiredaccounting.co.uk> #58
+1 please fix this issue.
ty...@gmail.com <ty...@gmail.com> #59
Same problem. Please fix ASAP!
dw...@fcpsschools.net <dw...@fcpsschools.net> #60
When are you going to fix this? It was reported back in November, 2017.
Either, Google is OK with multiple account sign-in on a single browser; or it is not.
Looks like Google wants us to continue to be able to use multiple accounts --- then PLEASE FIX this bug!!
Either, Google is OK with multiple account sign-in on a single browser; or it is not.
Looks like Google wants us to continue to be able to use multiple accounts --- then PLEASE FIX this bug!!
am...@autlan.com.mx <am...@autlan.com.mx> #61
+1 please fix this issue.
sa...@gmail.com <sa...@gmail.com> #62
+1 same problem
np...@paulinocontadores.com.ar <np...@paulinocontadores.com.ar> #63
+1 as well
vl...@ext.doordash.com <vl...@ext.doordash.com> #64
Really? Assigned?! Is supposed to be solved soon? :D Party day
jo...@bbva.com <jo...@bbva.com> #65
I apologize for the lack of a reply on this issue for so long. The bug was being tracked internally, but there hasn't been any progress to date.
The history here is that for a long time Google's multi-login feature only allowed you to be logged in to one @gmail.com account and one G Suite account (per-domain). Around the time this bug was filed, the multi-login system started permitting multiple @gmail.com accounts and multiple G Suite accounts from the same domain to be signed in at once. This broke some assumptions in the Apps Script code, leading to this behavior.
As mentioned earlier in this issue, the best you can do at the moment it try to detect this behavior and show an appropriate warning to the user. I'll raise this issue again with the engineering team to see if we can get some traction.
The history here is that for a long time Google's multi-login feature only allowed you to be logged in to one @
As mentioned earlier in this issue, the best you can do at the moment it try to detect this behavior and show an appropriate warning to the user. I'll raise this issue again with the engineering team to see if we can get some traction.
ku...@coefficient.io <ku...@coefficient.io> #66
Thank you for the explanation and status update!
ma...@gmail.com <ma...@gmail.com> #67
Comment has been deleted.
dr...@gmail.com <dr...@gmail.com> #68
This has been a really challenging but for me and my add-on, so I've been tracking it closely, and it seems like since yesterday 3/26 it hasn't been an issue! Would someone at Google like to confirm if this has been resolved?
cr...@stmarys-ca.edu <cr...@stmarys-ca.edu> #69
This is really torturing developers. The users keep complaining... Eric Koleda, please help
ce...@bbva.com <ce...@bbva.com> #70
Comment has been deleted.
te...@detechcentral.com <te...@detechcentral.com> #71
When will Google fix this major issue?
lo...@gmail.com <lo...@gmail.com> #72
Adding my +1 that this issue affects me as well.
dr...@gmail.com <dr...@gmail.com>
ps...@gmail.com <ps...@gmail.com> #73
This is one of the worst issues. Still no action is being taken by Google Engineers.
Kindly request to solve this issue.
Kindly request to solve this issue.
ty...@maryland.gov <ty...@maryland.gov> #74
I apologize the lackluster response we've had to this issue so far. I've been able to easily reproduce this issue when logging into two consumer (@gmail.com ) accounts, where the first account hasn't authorized the script and the second has. I've raised this issue with the engineering team again and will press them to take action.
te...@workday.com <te...@workday.com> #75
That's great news! Thank you.
ty...@gmail.com <ty...@gmail.com> #76
Thank you Eric
jm...@wayfair.com <jm...@wayfair.com> #77
Thank you for the update, Eric!
cg...@mecojax.com <cg...@mecojax.com> #78
Any updates so far?
This is a nightmare, Users are complaining severely.
This is a nightmare, Users are complaining severely.
cv...@gmail.com <cv...@gmail.com> #79
Gentle Bump, still no fix ?
ke...@cheffer.co <ke...@cheffer.co> #80
fl...@nextcanada.com <fl...@nextcanada.com> #81
Asking about this again.
tu...@ahaa360.net <tu...@ahaa360.net> #82
Many users reported today again about this issue. @Eric Koleda any update on this issue?
The issue happens in all the add-ons, for Forms and Docs as well.
The issue happens in all the add-ons, for Forms and Docs as well.
zh...@gmail.com <zh...@gmail.com> #83
same problem here. Can't update my data studio dashboards with sheets
fl...@gmail.com <fl...@gmail.com> #84
Same problem with our Slides Add-on, for some users it blocks the execution of a function and leads to a "Action not allowed" in StackDriver.
ad...@whirlpool.com <ad...@whirlpool.com> #85
Same problem for me in sheets
da...@travisperkins.co.uk <da...@travisperkins.co.uk> #86
Problem still persists, nobody at Google cares... 😒
ah...@gmail.com <ah...@gmail.com> #87
Still experiencing the issue
jw...@shift4.com <jw...@shift4.com> #88
Still experiencing this issue
ja...@denvershadecompany.com <ja...@denvershadecompany.com> #89
Comment has been deleted.
mi...@randstad.it <mi...@randstad.it> #90
G- accon add on is the same issue right now ?
ca...@bbva.com <ca...@bbva.com> #91
Eric Koleda what is the status of this issue?
On Tue, Oct 8, 2019, 1:23 AM <buganizer-system@google.com> wrote:
On Tue, Oct 8, 2019, 1:23 AM <buganizer-system@google.com> wrote:
ce...@notaria26gdl.com.mx <ce...@notaria26gdl.com.mx> #92
UP. The issue is really critical. It has persisted for 2 years already and certainly requires a higher priority.
ed...@acate.com.br <ed...@acate.com.br> #93
We are seeing similar issue with our Google App. When logged in with multiple accounts, the authorization requests goes into an endless loop. Please see my screen video:
https://www.loom.com/share/041f54803ba04e1b8eb0c0c8ebc51f73
rd...@cimtcollege.com <rd...@cimtcollege.com> #94
It's been two years since @streak reported this issue and it's still strong
... just marking the date
🎂🎂
@google: any update or good news coming ??
... just marking the date
🎂🎂
@google: any update or good news coming ??
da...@cityblock.com <da...@cityblock.com> #95
+1
ja...@powerbackrehab.com <ja...@powerbackrehab.com> #96
🎂🎉🎁
Happy birthday issue #69270374!
I never would have guessed we'd make it this far together.
Happy birthday issue #69270374!
I never would have guessed we'd make it this far together.
he...@gmail.com <he...@gmail.com> #97
Not only add-ons, but also this is a HUGE problem for Apps Script Web Apps,
too, that includes right-click Google Drive.
Steve Webster
On Wed, Nov 13, 2019 at 4:39 PM <buganizer-system@google.com> wrote:
too, that includes right-click Google Drive.
Steve Webster
On Wed, Nov 13, 2019 at 4:39 PM <buganizer-system@google.com> wrote:
je...@informedk12.com <je...@informedk12.com> #98
Happy birthday 😁😒
Ar...@ahschools.us <Ar...@ahschools.us> #99
Just spent several days and a few remote support sessions with one of our user on the other half of the globe to discover the problem is having something to do with this issue.
I can imagine more users may encounter this same issue.
It's been two years. Will anyone please take care of this bug? Finger crossed.
I can imagine more users may encounter this same issue.
It's been two years. Will anyone please take care of this bug? Finger crossed.
yo...@navagis.com <yo...@navagis.com> #100
Some for me. Set up a dummy personal Gmail account to do some simulated customer emails and now when I try to open the script editor from a sheet owned by my work Gsuite account it opens the script editor as my test personal account. I can't switch users at that point.
sy...@aftb.org.uk <sy...@aftb.org.uk> #101
Hi All, thanks for the diligent follow-ups! Want to rest assure you that while I can't comment on the status of this bug, the team is very much aware of it. I'll update this when a more substantial update is available.
ad...@cislink.nl <ad...@cislink.nl> #102
+1
jo...@bbva.com <jo...@bbva.com> #103
Only having this problem when we turn on V8 for Google Apps Scripts.
No hard feelings, but 2 years for this?
No hard feelings, but 2 years for this?
md...@dpsk12.net <md...@dpsk12.net> #104
+1
kb...@gmail.com <kb...@gmail.com> #105
+1 same issue when switched from OAuth2 App Script library to setting scopes into the appsscript.json and V8
al...@bbva.com <al...@bbva.com> #106
Any news for March? or 2020?
jp...@google.com <jp...@google.com> #107
Sure would be helpful for users to have this addressed soon.
jp...@google.com <jp...@google.com> #108
Another vote for this to be fixed. The AppScript issue is super annoying.
ad...@cislink.nl <ad...@cislink.nl> #109
+1
dr...@gmail.com <dr...@gmail.com> #110
+1
ga...@severaltech.com.ar <ga...@severaltech.com.ar> #111
+100
ed...@gmail.com <ed...@gmail.com> #112
+1000
Do you guys need engineers?
I'm looking for a job.
Do you guys need engineers?
I'm looking for a job.
te...@detechcentral.com <te...@detechcentral.com> #113
does anyone have a code workaround for this even? a way to detect that the user is going to fail the request. silently failing has resulted in two negative reviews of people saying the app doesnt work when i know it works just fine. if i could just show an error message when i knew this was the problem i could at least prompt the user to log into the correct account
la...@gmail.com <la...@gmail.com> #114
Bad reviews have been a common problem since 2 years.
No engineer is concerned about this issue so far.
I am already frustrated with this issue. Thanks to Romain Vialard for his
code snippet.
https://sites.google.com/site/scriptsexamples/home/announcements/multiple-accounts-issue-with-google-apps-script
On Fri, Mar 20, 2020, 9:20 PM <buganizer-system@google.com> wrote:
No engineer is concerned about this issue so far.
I am already frustrated with this issue. Thanks to Romain Vialard for his
code snippet.
On Fri, Mar 20, 2020, 9:20 PM <buganizer-system@google.com> wrote:
ma...@parqueexplora.org <ma...@parqueexplora.org> #115
Comment has been deleted.
al...@gmail.com <al...@gmail.com> #116
This issue has cropped up for me on EVERY sidebar called from an installable onOpen script. We were not having issues until this last weekend.
ma...@toho.ne.jp <ma...@toho.ne.jp> #117
To all subscribed to this issue:
There is a workaround, which I succesfully implemented in my addon 2 years ago, when developing it.
You probably just need to check if current user equals to document owner, and depending on that either use functions that require auth.FULL mode, or just show a sidebar with information for user, that he should log into document owner account.
var owner = Session.getEffectiveUser().getEmail();
var current = Session.getActiveUser().getEmail();
if (current == owner) {
//YOUR CODE FOR AUTH.FULL
} else {
//YOUR CODE FOR AUTH.NONE/LIMITED
}
in...@counselingbydaleth.net <in...@counselingbydaleth.net> #118
er...@gmail.com <er...@gmail.com> #119
So I've built this app script for my G Suite domain, and want to put it on our Google Sites page. We're a G Suite outfit, and Chrome is our browser of choice, so this should all be great! In order for my users to be able to get into the site, they have to be a member of the domain so everything should be peachy! Even with multiple logged in users, they can get in to the site just fine. When they go to the page with the app, they are denied access because of their second account.
The only way around this, without having the user sign out of the account, is to set the application as publicly accessible. Clearly I don't want the application to be public, or I wouldn't have put it on our G Suite site that's private, right? I don't have a choice there, so now that's done, I realize Google Sites doesn't allow the app to remain in it's ridiculous series of built-in iframes on the page, so when you change pages, it opens them on top(changes to the url of the application). Still works! Still Happy! ... wait... that means anyone and their brother can use my app if they have the link that's right there in plain sight in their search bar. (Yes, I know someone would essentially need to send it to them, but it's an unnecessary vulnerability now that the private information can be reached publicly.)
I'm trying really hard to be a nice admin and not make people log out of their accounts, so I use the Session.getActiveUser().getEmail(); and check if they're a part of my domain to grant access. Not a big deal right, they are on the site, it's working, and they are a part of my domain so, according to Google, it should work perfectly. (Just a reminder, they are logged in to a private Google Site that verifies they are using Google Suite Domain credentials to access a Google App Script.) Alright back on tra... WHAT!? If they are logged in to any other, non-my-domain account, it returns nothing. Zip, zero, nada, zilch. Great, can't fix it programmatically or by using all of the many broken Google settings, so let's tell the users to sign out of their secondary accounts.
I go click on the avatar, and go to sign out of the second account, and my only option is sign out all. OK, I'll sign everyone out, then sign just the good user back in. Everybody out, logged the good user back in... and there are still 2 accounts. I did a little digging and found out that the only option to log out of a secondary user account is to remove the account. OK, so keep reading, how do I do that... of COURSE YOU CAN'T! You have to essentially reset Chrome to log out of a second account. For multiple user stations, if you don't want to make them all sad, you can delete cache folders for just the effected users.
So, to recap. In an effort to increase your viewing pleasure Google has removed all app script security, and broken a great deal of their own services and functionality. Great job guys! I hope no one with protected data is still using app scripts and sites, because it's either not accessible, or publicly available. And it's been how many years now that you've known about ALL of these things that "mysteriously" happened right around the same time, and you've attempted to fix approximately 0 of them. Seriously, go look at the issues I just mentioned, open tickets for all of them, all of them being ignored.
What good are you guys, really, if nothing you do actually works the way you say it does and makes our data unsafe?
The only way around this, without having the user sign out of the account, is to set the application as publicly accessible. Clearly I don't want the application to be public, or I wouldn't have put it on our G Suite site that's private, right? I don't have a choice there, so now that's done, I realize Google Sites doesn't allow the app to remain in it's ridiculous series of built-in iframes on the page, so when you change pages, it opens them on top(changes to the url of the application). Still works! Still Happy! ... wait... that means anyone and their brother can use my app if they have the link that's right there in plain sight in their search bar. (Yes, I know someone would essentially need to send it to them, but it's an unnecessary vulnerability now that the private information can be reached publicly.)
I'm trying really hard to be a nice admin and not make people log out of their accounts, so I use the Session.getActiveUser().getEmail(); and check if they're a part of my domain to grant access. Not a big deal right, they are on the site, it's working, and they are a part of my domain so, according to Google, it should work perfectly. (Just a reminder, they are logged in to a private Google Site that verifies they are using Google Suite Domain credentials to access a Google App Script.) Alright back on tra... WHAT!? If they are logged in to any other, non-my-domain account, it returns nothing. Zip, zero, nada, zilch. Great, can't fix it programmatically or by using all of the many broken Google settings, so let's tell the users to sign out of their secondary accounts.
I go click on the avatar, and go to sign out of the second account, and my only option is sign out all. OK, I'll sign everyone out, then sign just the good user back in. Everybody out, logged the good user back in... and there are still 2 accounts. I did a little digging and found out that the only option to log out of a secondary user account is to remove the account. OK, so keep reading, how do I do that... of COURSE YOU CAN'T! You have to essentially reset Chrome to log out of a second account. For multiple user stations, if you don't want to make them all sad, you can delete cache folders for just the effected users.
So, to recap. In an effort to increase your viewing pleasure Google has removed all app script security, and broken a great deal of their own services and functionality. Great job guys! I hope no one with protected data is still using app scripts and sites, because it's either not accessible, or publicly available. And it's been how many years now that you've known about ALL of these things that "mysteriously" happened right around the same time, and you've attempted to fix approximately 0 of them. Seriously, go look at the issues I just mentioned, open tickets for all of them, all of them being ignored.
What good are you guys, really, if nothing you do actually works the way you say it does and makes our data unsafe?
nn...@gmail.com <nn...@gmail.com> #120
Hi Everyone,
We apologize for the delay. This issue is actively being looked at and we should have an approximate ETA for resolution by the end of the week.
Thank you for your patience.
We apologize for the delay. This issue is actively being looked at and we should have an approximate ETA for resolution by the end of the week.
Thank you for your patience.
gh...@gmail.com <gh...@gmail.com> #121
Experiencing the same issue. Any updates?
mi...@ambeagrofoods.com <mi...@ambeagrofoods.com> #122
A note of cautious optimism
- we haven't logged this error for 5 continuous days now
- that never happened before in the almost 2.5 years of this issue's life
- we haven't logged this error for 5 continuous days now
- that never happened before in the almost 2.5 years of this issue's life
ra...@gmail.com <ra...@gmail.com> #123
Then why did I get an error message with 288 occurrences? Why do I get error messages every day since 03/27/20? Each email has hundreds of occurrences. Can you correct this? I don't know how to email all of them to you. I can only send them one at a time. Tell me why I'm getting these error messages every day. How can it be stopped?Christian Doster(727) 216-7472christianpaul5401@gmail.com
-------- Original message --------From: buganizer-system@google.com Date: 4/8/20 11:22 AM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re: Issue 69270374 : Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple gmail.com accounts Replying to this email means your email address will be shared with the team that works on this product.
https://issuetracker.google.com/issues/69270374
Changed
fa...@thexs.ca added comment #122 :
A note of cautious optimism- we haven't logged this error for 5 continuous days now- that never happened before in the almost 2.5 years of this issue's life
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiplegmail.com accounts
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker issue 69270374 where you have the role: starred.
Unsubscribe from this issue.
-------- Original message --------From: buganizer-system@google.com Date: 4/8/20 11:22 AM (GMT-05:00) To: b-system+741193042@google.com Cc: christianpaul5401@gmail.com Subject: Re:
Changed
fa...@thexs.ca added
A note of cautious optimism- we haven't logged this error for 5 continuous days now- that never happened before in the almost 2.5 years of this issue's life
_______________________________
Reference Info: 69270374 Unexpected "authorization is required" error from google.script.run after installing Sheets add-on while logged into multiple
component: Public Trackers > G Suite Developers > Apps Script
status: Assigned
reporter: he...@streak.com
assignee: ap...@google.com
cc: he...@streak.com, le...@google.com, mc...@google.com
type: Bug
priority: P1
severity: S2
blocked by: 132238897
hotlist: Google Domain
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
Description
Uncaught TypeError: vb.X is not a constructor occurs in GAS web app