I'm following https://developers.google.com/drive/web/manage-sharing#launching_the_google_drive_sharing_dialog_in_your_app to add a "Sharing" dialog to my Drive app.
It works perfectly when the user is logged into gmail with a single Google account. If they log in to gmail with a second account, the ShareClient in my app no longer works. Instead, it says "Sharing is unavailable at this time."
To be clear, the change happens after interacting only with gmail, NOT with my app. I guess the problem happens because the share dialog doesn't know which user to default to.
Does anyone have a way to make this work? I would be happy to specify a google id, but ShareClient doesn't seem to have any settings exposed besides appId.
This is an issue we are currently aware of and will fix.
There isn't really a good way for you to work around it at the moment, so hang tight until we address it.
Related
I've seen other questions who shared this same issue here and here, but the solutions are not working for us. Our users are confused with the checkboxes since they haven't seen them on other apps before and it's making them more paranoid about the access they give.
Our app requires contacts and calendar read-only access to function, and i've tried many tricks mentioned by others but none of them worked:
We added email, profile, openid in Cloud Console scopes, the checkboxes still appear
We split login from authorization access, the checkboxes still appear.
Are we missing anything?
It seems if we only ask for 1 permission, it might solve the problem, but it's too inconvenient to ask the user to open 3 popups to authorize access.
Feedback to Google Team:.
Granular permissions are definitely in the right direction for user privacy,
but:
Process penalizes apps with granular permissions (e.g. if i ask for all calendars.readonly, and events.readonly, those force to show 2
checkboxes, whereas if i ask for only 1 super permission like
Calendly's "edit/manage/delete all calendars and events", it doesn't
show a checkbox.
Introduces a lot of inconvenience and unnecessary fear for the user.
Not all apps have the same granular permissions, and it's rewarding old apps (like Calendly) who are not yet impacted by granular
permissions, whereas new apps are inherently disadvantaged.
Ideas:
Allow app developers to select which permissions are optional vs required
Add an explanation field that shows the utility next to each permission requested to the end-user, and this could be added to the app review
process for sensitive scopes.
Make authorizing new permissions super fluid 1-2 clicks away, instead of opening a popup. Think how mobile apps ask for contacts
permission, it's granular, contextual and only 1 click away.
The workarounds that you mentioned may work but it seems that Google has announced this change on this behavior since 2018. Looks like the behavior happens when the app is requesting access from different services as noted in this Project Strobe blog.
There will be no direct way to remove the granular scopes if your app would be requesting permissions from different services as this will force the granular permissions to show up.
I am trying to run
this simple Google Script.
However, it does not allow me to authorise. How can I proceed?
Update 1:
As reported by
Rubén, Google says it won't fix this - #163
Some workarounds are provided in #76, #145 and #150 - showing solutions like changing GCP and providing a oauth consent screen.
Update:
Switching Google cloud project from default to a standard project have resolved the issue for some users. This is still a workaround and may not work for all. Therefore, star the issue below.
This seems to be a new issue affecting certain users. You can ★(on top left) star the issue here to let Google developers know that you're affected by this issue and to prioritize the issue.
It stopped complaining once I specified the script only needed access to the current sheet. Google explains how to do it here.
All you need to add to your code is this JsDoc annotation:
/**
* #OnlyCurrentDoc
*/
That's something that happens. To solve the issue just copy the contents of your Script, delete it, and create a brand new one with the same contents, or give it another name in case you are superstitious. If that doesn't work, create another Spreadsheet with the same contents and proceed. Sometimes it's just a temporary issue. Perhaps the problem persists due to the stored browsing data, so it would be convenient to clear it. (I challenge you to take this last move!)
After going through the process twice with a client, I can confirm that the most reliable way to fix the error currently is to go through the verification process. An important note is that after approving the scopes, some accounts need to approve every other sensitive scope that is added to the script and cloud project as well or the issue will resurface.
So the step-by-step guide is as follows:
Switch from default to standard Google Cloud Project
Fill in the OAuth Credentials screen and add all sensitive scopes
Click on "Submit for verification" and prepare a YouTube video showing both authorization process and usage of each of the sensitive
scope
Wait until the verification team sends you an email (usually 1-2 days, but no guarantee here) and reply with the link to the video, then wait for the verification process to complete
If you received a "Granted" response, continue to steps 6 & 7, if not - follow the instructions provided
Remove all previously granted permissions to the project
Reauthorize the script by running it again, everything should be working
Having the same issue no solution of listed in this thread were working for me. After faied authentification i always get the screen as the topic starter gets it, without the "advanced" option.
However i've managed to get at least a limited access and run my script on the following way:
I share the affected sheet to anybody with link, with editor access level.
Then, from incognito window (maybe it isn't necessary, but i did it so), I've logged in into my other Google account,
opened the link, which was shared,
was forced to authorize myself,
failed on authorization - but the screen with failed authorization contains the "advanced" option,
clicking on it i've got a limited access and was able to run the script.
I'm bumping into a weird problem in Google Apps Script, working on a Slides add-on.
When I run the add-on in an incognito window with just one user logged in (call it User B), everything works fine.
When I run the add-on with multiple users logged in (call it Users A and B in the same Chrome tab), it seems like Apps Script gets confused around the authorization. When I try to use the add-on as User B (as evidenced by the profile showing up in the upper right corner), all functionality of the add-on fails, I'm guessing because it lacks authorization. Note that the add-on has remain installed on User B's account this whole time, and it still works in the incognito window with just User B logged in.
Any tips on this? Is there a way to "force" the add-on to use the authorization of User B in the multi-logged-in case?
Having multiple log-ins active in the same browser is known to cause issues with Google Authorization.
The default account (typically the account that was first logged into) takes precedence over any other accounts. Google has yet to fully resolve this. Current work-around is to recommend to your users to log out of all other accounts.
I had the same problem and got it solved by changing the link as follows:
https://script.google.com/a/{any_character}/macros/s/{deployment_id}/exec
Note that my app was set public so anyone can access it.
Use this url to test instead:
https://script.google.com/a/{domain name}/macros/s/{token}/exec
I'm using multiple Google accounts. In one of them (not default) I created Google Spreadsheet file and I want to create Script connected to it. Nothing complicated. But the problem is that after clicking Tools > Script Editor I'm being redirected to default user or I see this screen:
The same problem I have when trying to use: script.google.com
What can I do to enable Script editor?
I know you asked this 9 months ago, but here is my solution;
Sign out of all google accounts except the owner of the spreadsheet
You can now access the scripts and macros pages (go there)
Create a bookmark of them (this saves which profile is logged in)
Now sign back into all your profiles
Voila!
You will be able to access the scripts or macros via the bookmarks without getting the error page.
This is a reported bug.
Go give it a ☆ if you want to let Google know that this affects you.
You can consider appending authuser=email to the URL to open the script with a specific Google account.
For example, script.google.com...?param=value&authuser=email#example.com
I was not able to reproduce the problem. Perhaps it's a glitch or there is something wrong that requires some troubleshooting techniques that are off-topic on this site.
As a workaround, for the account having problems, use another Google Chrome profile, Incognito mode, or another browser.
By the other hand, it's possible that there isn't any wrong and it's just something related to your specific scenario.
From Sign in to multiple accounts at once
Sometimes settings might carry over
If you're signed in to multiple accounts at the same time, sometimes we can't tell which
account you're using. For example, if you're signed in to two accounts
and you open a new browser window, we aren't sure which account you
want to use. In cases like these, Google might apply settings from
your default account, like its Web & App Activity and Ads
Personalization settings.
google's default account (the first one you sign on with) has to be the owner of the sheet
Based on #iansedano's answer, you can share the file with the default chrome user and open the same link in a new tab again to resolve the issue.
If someone needs a quick fix for this :
At the end of the url change the "authuser=1" by the index of the Google Account you want to log with. (0 is the first one, 1 is the second)
https://i.stack.imgur.com/qJows.png
You can also open a new incognito window, paste your sheet url there (you'll need to authenticate). Then you can open Tools -> Script Editor
I think this is the same as my question: http://code.google.com/p/google-apps-script-issues/issues/detail?id=852
But just to be clear: Google apps scripts won't run on a Google Site without a google/gmail user being signed in?
...are there other google products where GAS can be deployed for non-google accounts?
Thanks,
Nathan
False. You can embed an Apps Script in a Google Site using Insert > Script Gadget. Just be sure that the publishing setting is set to "Anyone, even anonymous".
You've got two different levels of user identity at work here, if not three or more. I will try to pull them apart for you in a clear way.
Google Sites can work for users of Google and non users. It depends entirely on the sharing settings for that site. If you share it with the world, it will be shared and indexed by search engines. If you share with anyone with link, search engines won't index it but no user will have to sign in to use the site.
What you are embedding in a Google site may have it's own user identity issues. The easiest way to manage these is to go into 'Publish' menu, and 'deploy as Webapp'. You will then see a menu that asks which account the script should be run under, essentially you or the user. And then which people to allow access, which you would select 'Anyone, even anonymous'.
This will run that app as your account, but allow anyone to call it. Works great for allowing the public access to a form created in GAS.
Now the other problems. It may be possible for you to have code in your GAS that specifically calls for a user. In that case all of the prior settings don't matter. When the script looks for a user and finds nothing valid it will error. These call are pretty obvious though and are more rarely used. (At least in my experience.)
But, in short, yes! You can certainly embed GAS into Google sites to be called by anonymous users.
Example of mine: https://sites.google.com/site/greenmountainretreat/sign-up
The issue you are referring to is about inserting i-frame gadgets into non-Google sites... please don't confuse things... and read the issue report thoroughly.
If you want another example...