When a new user accepts an invitation for a new account to use my program by clicking a URL I have to accomplish in script:
copy data from a template spreadsheet to a new spreadsheet for the new user
There are several conditions to work around:
- the template spreadsheet to copy resides in the administrative account
- the web app for the user is configured to log with the user's account, not my administrative account
I am struggling with how to read and copy the template spreadsheet data while logged into the user's account? As Google Apps has no scriptable interface for accessing a spreadsheet from a different account..even though the user will have read privilege to the template spreadsheet.
I have contemplated different ideas but am not sure..can I chain web apps together and pass data between web apps accessed from different accounts? Or, do I have to script a totally new data store other than spreadsheets and Google Drive? The new data store would have to be accessible from both the administrative account and a user's account.
If you program is a GAS WebApp, then deploy it from your admin account with settings:
Execute the app as: me (admin.account#yourdomain.com)
Who has access to the app: Anyone
This way the server-side code of your app will run under admin account, and will have access to your template spreadsheet, and signed-in users will be able to interface with the client-side of your app. You may have to implement some user authorization in your app, so only specific users who received an invitation are allowed to access it. For example, you can store users' email addresses in a sheet in your admin template spreadsheet, and check if current use is in the list before creating an account for the user. Session.getActiveUser().getEmail() will give you current active user's email address. Similarly you can check if an active user already has an account created.
If your program is not a GAS WebApp - please edit your question to add more pertinent details.
Related
Context:
I have a service account that updates a Google Sheet on a daily basis and I want to add functionalities to the Sheet by extending it with Apps Script. I developed the script with my own personal account (same I used to create the service account) and it seems I can't access the service-account information when it's making changes to the Spreadsheet. What I mean is that I set up a trigger for changes on the spreadsheet but when I try to verify who made the changes I get a blank string.
Quoting the docs:
The circumstances in which the email address is available vary: for example, the user's email address is not available in any context that allows a script to run without that user's authorization, like a simple onOpen(e) or onEdit(e) trigger, a custom function in Google Sheets
How do I fix this? Is there a different design I should use?
Service accounts are not real users, this can be noted in this documentation. Please note the following:
Service accounts do not belong to your Google Workspace domain, unlike user accounts. If you share Google Workspace assets, like docs or events, with your entire Google Workspace domain, they are not shared with service accounts. Similarly, Google Workspace assets created by a service account are not created in your Google Workspace domain. As a result, your Google Workspace and Cloud Identity admins can't own or manage these assets.
Service accounts do not have passwords, and cannot log in via browsers or cookies.
The triggers that are setup on your script would require them to be logged in to the browser in order to capture the email address, a service account can't do that so that would be the reason why you are unable to gather this information.
In a GAS published as webapp bound to a spreadsheet in a public (free) Gmail account, I'm compiling information from many unrelated users into that spreadsheet, where any Gmail user account can access the webapp.
But when script is run as the user, the user can access the app (after user grants permissions to the app), but it stops at point where script accesses the spreadsheet. The user is told to request access. I have to "share" the spreadsheet to the user for the app to function when run as that user, but that is problematic--too many potential users.
If another version of the script is run instead under my account, then user has access to the webapp, but the script cannot access the user's Gmail address. Big problem because the webapp must have the user's Gmail address for security/application access controls.
(The webapp is in development and Google "approval" has not yet been sought.)
How do I have a webapp (a) that modifies content in a central spreadsheet, (b) that any Gmail user can access, (c) where the script has access to Session.getActiveUser().getEmail(), and (d) the user does not need to have edit permissions for that central spreadsheet? The only user-account information that the script needs is the user Gmail address--again for application access control and security. (Since Google provides me a link that gives anyone full access to the spreadsheet (if they also have its URL), can't I give the bound script access to the spreadsheet when run under any Gmail account, where the integrity of the spreadsheet content is managed through the app's functions and internal access controls?)
If there is no solution except to run the webapp under the user's Gmail account and give that user edit rights to the spreadsheet, would that create significant risk (where I don't intentionally/overtly disclose the spreadsheet's URL) that a user could access and alter the spreadsheet beyond the insert/edit functions performed by the webapp? If that risk is low, is there a function I could use in the webapp to automatically grant spreadsheet edit rights to a Gmail account when its Gmail address is pre-registered in the user list for the webapp?
Thank you!
Let me start with c): there is no way to make that Session.getActiveUser().getEmail() works for free Google accounts (i.e. gmail.com accounts) other than for the container / script owner.
Regarding a) b) and d) you might use the Google Sheets API making the calls to it by using UrlFetch Service and a service account instead of the Spreadsheet Service or the Advanced Sheets Service.
Regarding allowing anyone to edit a central spreadsheet, once they open it either by using the Google Sheets apps or by means a web app, they will be able to find the spreadsheet in Google Drive > Shared with me among other places... IMHO the risk in terms of how likely is to have issues is big but in terms of the the impact depends on several factors, i.e. some changes might be reverted by using the version history but spreadsheet might become corrupted. If you have not used Google Sheets version history intensively the best is to get deeply familiar with it before relying on it as a backup / disaster recovery main tool .
From https://developers.google.com/apps-script/reference/base/session#getactiveuser
getActiveUser()
Gets information about the current user. If security policies do not allow access to the user's identity, User.getEmail() returns a blank string. The circumstances in which the email address is available vary: for example, the user's email address is not available in any context that allows a script to run without that user's authorization, like a simple onOpen(e) or onEdit(e) trigger, a custom function in Google Sheets, or a web app deployed to "execute as me" (that is, authorized by the developer instead of the user). However, these restrictions generally do not apply if the developer runs the script themselves or belongs to the same Google Workspace domain as the user.
Related
Use Apps Script URLFetchApp to access Google Datastore Data
Google Service Accounts / API - I keep getting the Error: Access not granted or expired. (line 454, file "Service")
I am using a Google Apps Script to change the signature of each user with personal data which is accessed via Directory API. Therefore I have a Service account with Domain Wide Delegation, which impersonates with an admin account to get all the users and their data and then impersonates which each and every user to change the signature via GmailAPI.
However now in addition I want to provide a Google Form for each user where the user can add additional information to its signature and set it. The script will need the users information from the Directory but I was wondering if the same approach with impersonating is needed.
With The Apps Script advanced Gmail Service it is possible to set the signature but I did not find a way to access the users data in the Google Directory of the specific user which is sending the form.
If I a service account is needed for that I was wondering where to store the access credentials for that? I don't want is be accessible by every user.
I have a timesheet application for employees of my company. I am not the admin. The application is a google apps script which takes the time sheet inputs and then writes them to a spreadsheet on my google drive. When I try to publish the app to users to run under their own login (company domain maintained by google mail), it states that "Users will be asked to authorize the script." Which means I have to give them the right to view the script. I only want them to use the url and see the pages rendered by the script.
Can the admin of the domain authorise so that all users using the email for the company can login using the email and use the script.
Do I need to transfer the script and the spreadsheet to someone with admin rights or can I continue to keep both on my drive and have admin authorise.
Regards
Which means I have to give them the right to view the script.
No, it doesn't.
I only want them to use the url and see the pages rendered by the script.
That's what they will see.
Can the admin of the domain authorise so that all users using the email for the company can login using the email and use the script.
No they can't because you set your webapp to run under the users login. One alternative is to create a service account which could be authorized by the domain-administrator to run domain-wide delegation of authority.
Do I need to transfer the script and the spreadsheet to someone with admin rights or can I continue to keep both on my drive and have admin authorise.
As explained previously, there is no need to have an admin authorize to keep your script code "secret".
i have an application (called:leave management) for my company that created from google sites(for UI), google spreadsheet(for Database) and integrated with google apps script. This application handled request for leaving, so, employee that login with company email can read and write the spreadsheet from google sites.
And here's the problem...i don't want the employee could edit the spreadsheet "DIRECT"...they should be write and read on the google sites...so the sharing settings for the spreadsheet must be "PRIVATE"...but it's impossible for read or write by other employee if the spreadsheet was "PRIVATE"...
in my mind...we can access the spreadsheet but we must have email spreadsheet owner, and the password too...it should be like this
var Sheet = SpreadsheetApp.openById("SpreadsheetID", "emailSpreadsheetOwner", "passEmailSpreadsheetOwner")
but yeah...it's doesn't work...
could you help me??
thanks :)
I use the same setup in an app, the spreadsheet is set to 'anyone with the link can edit' but no user knows the name or the ID of the sheet so they can only write and read through the UI and they'll never open the ss itself.
Isn't that what you want ?
There are two ways of deploying your application. Given your requirements, have your application run as the owner of the script and not as the 'User accessing the web app'
This way, you (the owner of the script) can keep the spreadsheet private, yet be able to write and read from it when a different user accesses the application.