I've a public Google Sheet (everyone can access it and edit it). In it, I use a script, a function, that download a csv with the UrlFetchApp.fetch(url);.
When an anonymous user access it (without the google login), the user can view, and edit the sheet, but, the user cannot run the script. The user must be logged with a google account to the script do the working.
The stranger thing is that this sheet with this script was working for anonymous users early. This problem didn't occur before a couple weeks ago.
Do you know if the google change something about security or is it an error that I am doing?
In order to run apps script on a particular user's behalf, Google Workspace requires that user's permission, via an OAuth flow.
If a user is anonymous therefore, you can see why this permission cannot be granted, which is why the script won't work for those users.
I guess it is an intended behavior as long as the anonymous user access the sheet via shareable link. As stated in this support page, you might see a name you don’t recognize or "anonymous animals" viewing your document, spreadsheet, or presentation. This can happen when a document is shared publicly or with anyone who has the link.
Limit how people can view your file
If you want to stop sharing a file you can edit, you can learn how to:
Turn off link sharing for a file.
Prevent others from sharing files you own.
Hope this helps.
Related
I have google sheets addon in Google Workspace Marketplace. I want to store the emails of the users installing the addon. I'm thinking of three possible ways.
Write to private spreadsheet under the addon account (different than the user's). Addon is running under user's so the question is, is this even possible - accessing the addon account (specifically writing to a spreadsheet) from within the user google account context?
using PropertiesService - Write the user to script properties using PropertiesService class.
One problem with this one is the limitations as explained in Quotas for Google Services.
for me, at lease for now, this is enough.
However the question is how to access those script properties programmatically.
Of course I can access the data from the script editor, but this is not practical if I want for example to send mail to all the users.
adding code to the addon that will be available only for specific users (admin). In this case since I can read the users from the script properties, and maybe write them to spreadsheet to be used later. This looks ugly, I admit.
I'm not asking for code solutions, but suggestions for the right or best approach.
The easiest solution is to create a database
Create a spreadsheet located on your Drive, shared as "Everyne can edit".
Implement a flow where after Add-n installation data containing the user"s email will be appended to the spreadsheet.
This request will take place on user's beahlf, however given that the spreadsheet is shared publicly, there won't be any access permission issues
Even if the spreadsheet is shred publicly - given that the spreadsheet id is not known by anyone other than the Add-on code, you do not need to worry about undesired access to the database.
Why am I not able to give permission/authorization to a Google Apps Script that I also made using the same Google account?
It seems like Google doesnt trust myself to use my own Google Apps Script with my own Spreadsheet.
Here is the line of code that breaks everything. If this line doesnt exist, I'm not asked for permission.
var sheet = SpreadsheetApp.getActiveSheet();
So it's trying to access the spreadsheet that created this Google Apps Script, also made using my account but I cant grant permission.
When I run the line of code above, I am told I need to give permissions, so I do by selecting the account name I am already logged into. I am greeted by this error,
This app isn't verified
which unfortunately does not provide competent documentation to troubleshoot.
Any feedback or help would be much appreciated! Thanks!
Click on the "Advanced" link and you'll be able to authorize your script.
To reduce the scope of permissions you request, you also have the option of declaring your script project to be only able to interact with the bound document:
/* #OnlyCurrentDoc */
function myFunction() {
...
This declaration is incompatible with some methods (such as SpreadsheetApp.openById()), and using an incompatible method results in an error in the application execution.
Successfully adding it to your project is generally sufficient to remove the "This application is unsafe" layer of the authentication flow, meaning the authorization and permission list is not hidden behind the "Advanced" tab.
In addition to declaring as current document only, manually editing the requested scopes of your project in its project manifest can help reduce the perceived threat from an unverified application (for example, retaining only the "read_only" version of certain scopes, where applicable). Apps Script documentation offers more details on project manifests.
Our organization uses Google Apps for Work. We have a Google Sheet "form" for employees/users to complete. After entering information, users are expected to use email as attachment/PDF. Finally, users click a "button" near the bottom of the sheet that triggers a script to clear user data. The first time a user clicks the button, an "Authorization Required" prompt appears, informing the user "the application" (script) "needs authorization to run." If approved, the prompt goes on to request View and manage your spreadsheets in Google Drive permissions for the script.
Is it possible to digitally sign or otherwise pre-approve a Google Apps Script for all users in a Google Apps organization so this prompt doesn't appear? We can/will include instructions for users, to head off questions / allay fear, but many of our users will either ignore or not understand the instructions and be perplexed.
I'm open to (and exploring) other options for tackling this (Google Forms/Sheets?), but prefer to stay in the (native) Google Apps environment as much as possible.
I couldn't find this question elsewhere and as best as I can tell, it isn't answered in Google Apps Script documentation.
I have found no way to pre-approve an organization/group/individual without manually doing it for each account.
You CAN deploy the script using a service account and have it run as that account. Then you are authorizing that account and the end user's accounts do not come into play. The drawback is that if you want the emails to go out using the end user's email, it won't happen. Plus the sending of the email would have to be from code in the app. That means all emails would go out using the service account's email address. (Although I am now wondering if it is possible to initiate the email without sending it. Basically pop it up as if a mailto link was clicked.)
You also will not be able to get the end user's name, etc. If these items are not important, or you can trust them to fill out their name where it may be needed (you could change the From name to what they key in) then running as the service account may work for you.
Karl
I wrote a google spreadsheet script incl. html service. Now I like to publish the html service as a survey. Everbody shall see it without registration at google but it should be not allowed to see the results of all participants.
Have you an idea how can I reach this?
I tryed a lot of publish options but I didn't reach my goal. Do you?
Right now, your Apps Script Project is probably bound to the spreadsheet. If the users who are submitting the form, never need to see the spreadsheet, then create an Apps Script file that is not bound to anything, it's "Stand Alone". Then do NOT share the spreadsheet. If you share the spreadsheet, then people who the file is shared with can VIEW the spreadsheet. It is possible to hide and protect sheets and ranges. And of course you can make settings for some users to be able to VIEW the spreadsheet, and others to EDIT.
If you share the spreadsheet file, then everyone it's shared with has VIEW permissions. You can't share a spreadsheet file and not give VIEW permissions. But, if you want some users to be able to see just some sheets in the spreadsheet, and not all the sheets, then you would need to write some code that ran when the Spreadsheet opened, and that code would be hiding and unhiding sheets depending on who opened the spreadsheet. Only users with EDIT permission can unhide a hidden sheet. So, that's an option. You can hide a sheet from anyone. But a user with EDIT permission can unhide the sheet. If you want to hide a sheet from someone with only VIEW permission, (They can't unhide it) then have code run onOpen() that checks the user, checks their permissions and either hides or unhides the sheet.
If the people submitting the form, never need to view the spreadsheet file, then don't even share the spreadsheet URL with those users. Just use the Stand Alone HTML Service as your "front end", "User Interface" with the users who never need to view the spreadsheet.
So, if the people who are using the HTML don't need to ever view the spreadsheet, then don't give those people the URL to the spreadsheet. Give them the URL to the published app. In that scenario, the users of the published app will never see the spreadsheet. The published app is essentially a website, with no real domain name.
The solution for you, depends on how simple or complicated the sharing, editing and viewing settings need to be.
When opening the script file, you need to use the Publish >> Deploy as web app option.
Then, choose the version you want to deploy as webapp or create a new one, set the app to execute as you, and add access to anyone (even anonymous). Like this:
The important thing is that the function that's called when someone access the URL that's shown for your web app, is a function called doGet(). So you must rename the function you use to display the UI and Form to doGet(). This function should return a valid HTML Output (normally using the HTMLService or the deprecated UiApp service).
So this:
Gets you this:
I have a spreadsheet with a UI app script. The app reads/updates from the spreadsheet.
My current settings are: Execute the app as "me".
Who has access to the app: "anyone".
I'm essentially sending out workflows that have assignments by email. Those emails can be outside of the domain but would all be gmail addresses.
I had hoped I'd be able to access the Session.getActiveUser() as I need to allow certain functionality on the app based on user accessing the UiApp. That function does not seem to provide any info unless I'm logged in as the script owner. Session.getActiveUser() is blank when accessing from a different address.
Is there a way to get the active user without having to Execute the app as "User accessing the app". I'd rather not have to share the spreadsheet with all the end users.
Thanks for any suggestions.
Rewrite from comments for readability :
Sharing the spreadsheet in this context doesn't mean anybody could open the spreadsheet directly as a document as long as the url of the spreadsheet remains unknown. The app will indeed need to have access to it if you deploy your app as 'User accessing the webapp' but no one can find the url of the sheet unless you publish it. I use this configuration very often but of course I don't know your exact use case... ;-) In my case the app itself determines what a specific user can do or not (by enabling /disabling certain functions / panels depending on the logged user.
Here is an example of an app like this, can you find the source spreadsheet ?
My spreadsheet has "anyone with the link" so the app can read and write to it but the name of the spreadsheet and its url is unknown (except for me) so it never appears in the document list of the user even if the user "writes" something in the document through the webapp (since he never actually "opens" it). I checked that on different accounts and never found any exception.
The active user and the property's like email etc.. Are not accessible with a public google account. It is accessible and useable with a google apps account within your own domain. See http://www.google.com/intl/en/enterprise/apps/business/pricing.html
Otherwise it's just a point of privacy on the web.
A litle disappointing i can imagine but logical if you think about it.
I do have another tip for you. Have al look at this link http://shop.oreilly.com/product/0636920023210.do
O'reilly also implemented a workflowsystem. It uses the url parameters to pass email (identity) information. Not really secure, but in combination with the Utilities.DigestAlgorithm SHA encoding you could take steps to encode your url email-parameters.
Hope this is helpfull.