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...
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.
Am I correct that there is NO direct replacement for this process on marketplace:
publish unlisted on chrome add-on store
directly share the link with others who can use the script
In particular, the mechanisms allowed me to use a script that I write across all my google dsocs.
With the move to marketplace, is there any way in which I can do this? I.e., write a script (container-bound or otherwise) and have access to it from ALL my google docs?
This is not about privacy: I am super-happy for the script to be shared with others or be public, but the review process has already turned down the script as unfinished. However, the script does what I need it to do... so I'd like to be able to use it across my google drive primarily... however, with the new google marketplace that doesn't seem to be possible.
One way may be via Google Suite domains. That seems to allow for internal publication. However, I've done that, and so far not received an acknowledgement or notification (while the GSuite page says 'under review'). My understanding was that internal scripts weren't subject to review.
Would anybody be able to comment on this and confirm, clarify or refute this understanding?
The move to Marketplace has certainly caused a lot of confusion! Trying to find all the tick-boxes can be difficult.
The two main places to look are the OAuth Consent Screen, where you need to make sure it is Internal (you have to have a GSuite account for that):
And the Marketplace SDK under Configuration check it is set to Private (although note that if it has transferred from the Chrome store it may already be set to Public, and this can't be changed). And under Publish it is set to unlisted.
This "unlisted" setting may be the crucial one for you as even if it is "Public" it won't be in the Marketplace, but will only be available via a link. But if it is "Public" I don't think you can make updates without going through the verification process. But if you don't go through the verification it should still be available.
Hope this helps, happy to answer any other questions.
Andrew
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 recently created a Google script for my documents but I'd like to know how to authorize all my documents to execute this one, not only the document that I used to develop the script...
First, Is that possible without passing on the store?
I have great news for you! Google says they're working on that!
But also bad news. They've been working on it for four years now, which really means they're not working on it.
See Issue 489, star it and wait for the announcement of project completion. He he!
The topic of sharing scripts among multiple documents has been covered before:
https://stackoverflow.com/questions/5334751/how-do-i-share-a-script-i-wrote-with-my-co-workers-on-the-same-google-apps-accou?rq=1
Libraries.
How to share one Google Apps script between few documents?
Libraries.
What happened to the "Publish to Gallery" option in Google Apps Script?
The gallery was retired.
Google Apps Script add code to copy of a document
Can't do it.
Option 1: As those previous answers suggested (and I'm sure there are more), turn your script into a library, then in every document you want to use it you "just" need to add a script that includes the library, and functions that call the library functions.
Option 2: Any stand-alone script can be "tested as an add-on", which allows you to associate a script with any document. Unfortunately, just one document at a time.
Option 3: (Your own suggestion.) You are able to publish through the store, but limit the visibility just to yourself (any account), people with the link (any account) or your organization (domain accounts). If you're using a consumer account, you'll have to pay $5 to register as a developer for this privilege.
I'm uncertain about whether you'd need to wait for a review cycle, or if your add-on would go live immediately, or if you'd be able to skip providing help documentation, support web site, etc. - maybe someone else can weigh in on that via comment, and / or update this answer with details.
The advantage to this would be the ability to have the script in any of your documents, without adding scripts to them.
Consumer account add-on visibility options:
Corporate domain account:
When I deploy my GAS project as a web app, I choose to execute the application as the user accessing it. The option for 'Who has access to the app' I can choose just myself, or everyone in my domain. This I understand.
However, in our Google Apps environment - the domain I belong to is one of many 'sub-domains' under one 'tld' domain to which I have an admin account. I don't have privileges to go full exploring in the control panel to see the exact organization, but I know that I can share docs to everyone in all domains via my Drive. How can I get my script to operate in a similar manner?
There are a couple of good resources on this topic.
Stackoverflow question which links to this
Google support answer
With Google Drive, "You cannot restrict sharing to the users in a single domain". I haven't found an answer to this, but this was the closest that I could find. It seems that you will just have to test if "Anyone in my domain" actually means "Anyone in my organization." If you can test this and report back, I will update this answer.