I am creating a Sheets add-on that works with our app. Our app uses Google OAuth for authentication.
I have the add-on working with manually configured credentials, but obviously that's not a real life solution. Now I need to have the add-on user authenticate to our app within the add-on itself, so we know whose account to work with.
User has data in Sheets -> user uses add-on to authenticate to app -> add-on uses app's API to push/pull data between Sheets and app for that user
I have tried using our API's login URL to get the HTTPResponse from Google using fetch() and loading it into a sidebar, but aside from it being ugly, it doesn't give me the expected option of choosing the Google account I want, but rather logging in from scratch, and when I enter my Google account, it doesn't do anything other than continue giving me errors about the frame being sandboxed. The threads here and here don't seem to address the issues as they're talking about iframe within the app, whereas I'm trying to use the sidebar in Sheets itself.
The app and the add-on are using the same GCP Project ID.
I need to get the same BearerToken that the app uses to use in the add-on.
Related
I can't seem to access a Google Scripts webapp via HTTP requests when it's exposed to only my workspace domain, though the same works when I allow anyone (even anonymous) to access it (from a personal account created for testing)
I'm currently trying to use the Events API from Slack's and listen to calls via a Google Apps Script. Here's what that looks like on Slack's side:
This is the screen I'm pasting the Scripts URL into
Now, if I do this with my personal account, it works with the following code in the script because I've configured it to run as myself and allow anyone on the internet to run it, even anonymously:
function doPost(e) {
var v = JSON.parse(e.postData.contents); // Added
return ContentService.createTextOutput(v.challenge); // Added
}
This is how the webapp's URL looks - https://script.google.com/a/macros/scripbox.com/s/{scriptId}/exec
However, if I try to do the same from my Google Workspace account, I don't have the option to allow anonymous users to have access. The broadest option I have is "Anyone within {{workspace}}". How can I add authorization to my script URL so that anyone from my workspace's domain is able to access/use this webapp via http requests?
Could somebody please give me some assistance or to refer me to a documentation or an article for the following.
I am developing a web app using Google Apps Script. Is there any way that I can set up the project so the web application could same time:
1)access the data ( gmail, calendar) of user who is running the app,
2)access the data of the app's owner / deployer but only throughout the app (For example I don’t want to give access to spreadsheet data outside the app i.e. I don’t want to share the spreadsheet with an user accessing the app),
I want to create a Google sheet add-on where the user can create an HTTPS endpoint in his sheet, that can act as a webhook for an external service. I can see it is possible to do this manually by launching app script code using the 'Deploy a script as a web app' option from the Script Editor
https://developers.google.com/apps-script/guides/web#deploy_a_script_as_a_web_app
Is it possible to automate this in app-script so that the user can configure this in the add-on UI only and in the background, app-script launches the endpoint and can return the endpoint URL to the user?
A Google sheets add-on is a single project shared across all users of the add-on. So, even if any user was allowed to use "Deploy as webapp" feature, Deploying it will create a single endpoint for all users of the addon and NOT a unique url endpoint for each user.
It might be possible but you'll likely need the user to grant your app access to restricted scopes, in which case your add-on will need to undergo a security assessment which will run you anywhere from $15,000.00 to $75,000.00.
You can try leveraging the Apps Script API to create a script project specific to the user and use that project to deploy a web app on their behalf. Not sure if it will work, but you can try playing with the following API endpoints:
https://developers.google.com/apps-script/api/reference/rest/v1/projects/create
https://developers.google.com/apps-script/api/reference/rest/v1/projects.deployments/create
https://developers.google.com/apps-script/api/reference/rest/v1/projects.deployments/update
What I trying to do here is an application that connects to bigquery, executes some query and writes a spreadsheet in current user's Google Drive.
I know that I can change the "Execute app as" option when deploying the app. But when I do this, and the user try to use the app, Google asks for permission to access the BigQuery.
I do not want to give permission to each user to access BigQuery.
We have about 50 ~ 100 users who will use (and this number can increase)
Some images:
When access the application's url: http://i.imgur.com/kGzJ3ps.png.
When the user clicks in the "continue" button:
http://i.imgur.com/4cRmhZ6.png
Hope I've been clear.
You would probably need an App, that had people sign in with their Google account using oAuth2
Google Accounts Authentication and Authorization
I think that this link gives an overview of what your options are:
Permissions and Types of Scripts
I guess you would need to have an App, that ran as User at the keyboard, so that the spreadsheet saved to their Google Drive. If you wanted the user to be able to download a file to their computer drive, that's a little different.
Just use HTML Service. It's basically just building a website. You just don't have a domain name. But the spreadsheet you are distributing doesn't have a domain name.
HTML Service Google Documentation
From an Apps Script HTML Service, you can write to Spreadsheets, Documents, and run HTTP Requests (urlFetch).
URL Fetch Service
The permissions in the Apps Script App can be set to run the Apps Script file as yourself, with access to anyone, even anonymous. That way, the user will never be asked for permission for any files that you own. You will need to authorize it once, the first time any script that needs access to your files is run.
Because anyone could run your Apps Script App, you might want to have a log in system to authenticate users.
You would need to use the Big Query API with Apps Script urlFetch to access Big Query.
So, with the HTML Service, you can do most everything you could do with HTML, CSS, and Javascript on a regular website. You can create custom input forms, have different pages and display data in tables. Plus it's served over HTTPS.
One solution that you can use if you don't want all your users to enable BigQuery is to use a webapp deployed as a service running as "you" and that will respond to an urlFetch coming from each user through the script they run as "themselves".
This service will be deployed as any other webapp using a doGet main function and return its data using contentService
Yes, that is possible. Check out this answer here: Using Advanced Google Services with Service Account and also check this awesome library: https://github.com/googlesamples/apps-script-oauth2
I have an app that consists of two parts
an installed application (more specifically: a browser add-on) that runs on the user's machine, and
a web app implemented as a stand-alone Google Apps Script app using HtmlService.
The two parts talk to each other and both access some Google APIs on behalf of the user via Oauth. To do this, I set up an API project in the Google API console. In the section "API Access", I created a client of type "Installed Application" for the browser add-on. For the Apps Script part, Google takes care of the authorization flow automatically.
My problem is that Google does not know that these two clients are part of the same project. Therefore, the user has to go through two authorization steps in a row when executing my app for the first time (first, the Oauth process for the browser add-on and then the automatically generated authorization process from Google Apps Script). This is very confusing to the user, especially, since the splitting between the browser add-on and the web app is rather an implementational detail about which the user shouldn't really have to bother.
Is there a way to unify the two authorization flows? I know that one can add several distinct clients to a single project in the Google API console. It seems to me like this feature is explicitly intended for scenarios similar to mine, where more than one application make up what is perceived as a single service by the user. Unfortunately, web apps that are implemented in Google Apps script don't seem to be compatible with the Google API console because of the way Apps Script generates the authorization flow automatically. Or am I missing an option in the API console or in the Apps Script editor?
For future reference: I found out that Google automatically creates an API project in the Google API console for each Google Apps Script project. This seems to be a fairly recent feature. One difficulty for me was that these API projects don't show up when one goes to the API console, clicks on the name of whatever project is currently opened in the upper left corner and chooses "open". Apparently, the only way to reach the auto-generated API project is as follows:
Go to drive.google.com and open the Google Apps Script project.
Chose "Resources --> Use Google APIs...".
In the popup, click the link to the Google API console.
In principle, this should allow to add additional clients to the project, as long as none of the other clients is also a Google Apps Script project. I haven't been able to test this since it still doesn't solve my specific problem: Sending e-mails from the user's Gmail account seems to be a feature unique to Google Apps Script and I couldn't find an Oauth2 scope for this operation. Therefore, I still cannot ask for all required permissions in a single authorization flow. But if anyone who's reading this has a similar problem with different Oauth2 scopes, the above instructions should fix it for you.
Anyway, I solved my problem in the meantime by no longer using Google Drive to upload files.