I have a script that I would like to make available to all the users of our Google Apps domain, but I don't want to publish it to the Chrome store. We would like to avoid deploying it from a single user account. How is this normally done?
It really depends on your use case, but there are a number of ways this might be achieved from publishing a code library (and limiting the sharing of the link), hosting it in a Google Site to publishing it as a url triggered webservice.
It depends on whether you want to share the functionality to others or literally the code.
Related
I'm trying to wrap my head around how the publishing options for Google Apps Script web-apps work. I have a GAS project that delivers a JSON API. I want other non G-Suite services to be able to call the web-app URL. I am on G-Suite enterprise and my GAS project is created in our GCP organization.
When I publish the web-app there are three options:
myself
anyone in my organization
anonymous
For various reasons, I cannot use the anonymous and obviously myself option won't work. So I have to use the anyone in my organization option.
Now, when a human, logged into a G-Suite account that is in the organization, goes to my web-app URL it will work as expected.
I have another web-site, outside of my organization. I want that web-site to call the web-app URL. I know everything online says to use the anonymous option but I cannot.
So I am wondering what options I have. I had some ideas but not sure:
Do something such that my web site server/account has a G-Suite account that is in the organization. That way, when the web server makes a call to the web-app URL it would look like its coming from a G-Suite account that is in the organization. Does that make sense?
Make the call to the web-app URL and pass some token information that would tell GAS to allow access.
Are either of these possible? Or are any other ways possible?
I got a little bit stuck right now at deploying my Google Script App.
I've developed a Google Script App, which is embedded directly into
Google Drive (Spreadsheet). It's not a Web App, it's a user interface
in Google Spreadsheet (sorry, but i have to be clear).
That Script is just for one person in another company.
How can i deploy my script to her?
I've read about Domain-Wide-Installation and publishing an App to the marketplace, but i want to deploy it just for her and no one else.
How can i achieve that?
Thanks
Best regards
A big thanks to Sandy Good.
"You can publish an Add-on as "unlisted", which means that it can not be seen in the Chrome Store, and does not need to go through the approval process. When an add-on is installed, it has the authority to check the users email address. So, you could set it up so that it could only be installed by this person. An Add-on will keep the code from being accessible to anyone. Although you might want to also use private functions. I don't know if there is a better way for the Domain Administrator in a paid account to do what you want. I don't know anything about that." - Sandy Good.
That was exactly what i was looking for. Thanks
An add-on can also published for testers. Those testers must be part of a google group. Maintaining a group is easier.
I read this:
https://developers.google.com/apps-script/guide_libraries
and
Distributing Google Apps Scripts for Sheets in your company network
I have a simple udf for google sheets that I'd like to share with a couple other people. Whenever I need it for a new sheet, I just copy and paste the code into the script editor and run a smaller function in debug mode. Then the computer asks if I give permission to my little script to run and I say yes. If other people want to use my udf, I can't expect them to do the same thing because they're not programmers. Well, I'm not either, but I try. Anyway, is there a way to share it without publishing an add-on or that domain admin sequence of events or anything involving long authentication strings or oauth2.0. all of this is too overwhelming for me as I'm not a real programmer.
Also, is there a way to share the udf without sharing the code, because the code is constructed embarassingly and more importantly, there is some info I'm not sure I'm allowed to share.
Speaking of things I'm not sure of, I'm not sure if this counts as an app for work because we use the app for work, but it seems like your company has to pay for something to be considered an app for work even though these apps seem like they're for free.
Apparently there is an open issue regarding Protect Google App Script. It would be best to follow this ticket to be update on how you would be able to protect your apps script code. Migrating your code to an external script and make it as a library would protect your code from editing but not from viewing.
Creating an app for your company may not be considered as an app for work. According to this document:
Google Apps for Work adds business-specific features such as custom email addresses at your domain (#yourcompany.com), at least 30 GB of storage for documents and email, and 24/7 phone and email support.
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...
I had several questions regarding the usability of a "G Suite/Google Apps API." I would like to integrate some sort of document/spreadsheet/presentation management directly into an application I am building.
This service would have to have the ability to import and export to DOC/XLS/PPT/PDF etc..., so something like Feng Office (if you have ever heard of it), wouldn't suit this need.
For this purpose, I'm looking into such a thing exists. Before I would begin this endeavor, I was wondering:
Do the G Suite/Google Apps productivity tools allow documents/spreadsheets/presentations to be created, read, updated, and deleted all from a third-party application?
Would potential users have to have a Google account in order to use document/spreadsheet/presentation editor?
Could multiple users on my application access files under one Google account, if an account is needed at all?
Last, is it possible to skip a Google account, and let Google docs directly access and save documents on my local server?
Sorry for the crash list of questions, but if there is anyone who could help with these, it would be much appreciated.
spryno724
Yes.
Not necessarily, you can have your backend script sign in as you, or even better, an admin account set-up specifically for your app.
Yes, see #2.
I don't think so.
(Feb 2017) The executive summary is that you can do what you envision, either by using G Suite (formerly Google Apps) APIs or Google Apps Script. TL;DR below in response to your "mini-questions".
Yes; you can do it with...
Individual app REST APIs, i.e., Sheets API, Slides API, etc., or just the Google Drive API.
Keep in mind that the Drive API is used for file-oriented functionality (create, delete, import/export, etc.) while the individual APIs are for document-oriented functionality (editing, formatting, etc.)
To learn about using the REST APIs, see the first few videos in this playlist, specifically videos 2, 3, and 4 to start with
An alternative that's more like using "services" vs. APIs but that can also programmatically CRUD G Suite documents is Google Apps Script, server-side JavaScript apps that are hosted at and run in Google's cloud. If interested, I created an Apps Script intro video for you.
FYI, videos 5, 8, 22, and 24 from the playlist above are for Apps Script if you want to pursue that
Note that neither Google Docs nor Google Forms currently have REST APIs, but you can programmatically access them from Apps Script.
Yes, users need to have a Google account but they don't have to create a Gmail address. See this page on creating Google accounts without Gmail. (If they do want to create a Gmail address, then they can use this page instead.)
Yes, you would use the Drive API to set the sharing permissions with your users. See this page on Permissions and this one on Sharing for more info.
Not really; you need at least one Google account in order to access Google Drive where the files would be stored. You can, however, manage the files on your own, then import to Drive and export from Drive to allow your users to edit on your servers then push them back to Drive. For more info on import/export formats/MIMEtypes, see my answer to another SO question.