Package as web app?

[rosulek]

If the script is going to start having multiple files + dependencies, it would be nice if there was a one-click way to install this. This is a good idea even if it's a single file, since not everyone will want to do the manual installation process.

Ideally I would host a version of the script from my google account. Anyone could click a button somewhere that installs it to their account.

I think the way it has to happen is to package it as a web app. These can somehow be configured to run as the user of the script (not the author of the script).

On the one hand, this seems possible. On the other hand, I still have not seen a reasonable proof of concept that accomplishes this. Actually, I feel like I saw one a few months ago but apparently didn't bookmark it.

Other things:

• A packaged web app can apparently add the appropriate triggers programatically.

• If the goal is user-friendly install, then there should also be a way to configure the tickler without having to edit the script manually (which is probably not even possible in a packaged web-app). I guess this can be done by manually making a web interface, and using Properties service as a user-specific key-value store. This seems like a bunch of work.

[dreeves]

My Gmail Snooze app does all that! It's like a simpler version of gmail-tickler that can only snooze for an integer number of days. http://dreev.es/snooze https://github.com/dreeves/gmailsnooze

[lehrblogger]

I agree that it would be great if we had a simpler way for new users to install the script. While it might work to package it as a web app, I have a couple of concerns:

• I am personally very reluctant to grant access to my Gmail account to third parties, especially when they aren't associated with established companies and/or when I can't read the code that's going to run. I'm not especially worried that the code itself will try to steal my information/identity, but security is hard, and that third party might inadvertently expose my information or access tokens to others. Maybe most people aren't as paranoid about their personal accounts, but it might matter more for users wishing to use the Tickler on their corporate Google Apps accounts.
• I think the config options make the Tickler much more useful, so I'd hate to lock most users in to the defaults. A web interface might work along with the Properties service, but I'd rather avoid administering another web server/application.

I don't have a perfect solution in mind, but a couple ideas:

• Can we automate the Trigger creation in the Script's setup() method? That might be worth doing independent of this issue.
• The Script is a Google Drive file like any other, so can be made accessible to anyone with the link, who can then copy and configure the Script. This is only a slight improvement over the current copy-and-paste, but it's a start.
• Alternatively, users could just authorize the existing shared Script. This doesn't really solve the security problem, however, since the owner(s) of the Script can still edit it after users have authorized it. This also doesn't give users a way to configure the Script.
• To solve the above security problem, could we take advantage of Script Versions and/or Included Libraries, to give users assurance about what version of the code they were running? I'm not sure exactly how this would work.
• To solve the configuration problem, perhaps we could create a Google Form that saved a user's configuration settings, along with their email address, to a master Sheet of preferences that only admins had access to. The Script would then automatically load the configuration from that Sheet for the user currently executing the Script. If we make the Form responses editable, users could update their responses at a later date.

[lehrblogger]

Oh, I think this issue is a duplicate of https://github.com/rosulek/gmail-tickler/issues/4 Bundle as web app. @rosulek, do you want to close that one, since there's a bit more activity here? This is @orschiro's comment:

(Figure out how to) Bundle the script as a web app that others can add easily. Wanted to share the following Chrome extension with you. Maybe you can take it as a reference to convert gmail-tickler into an easy installable Chrome extension:

https://chrome.google.com/webstore/detail/gmail-snooze/ajhdhpnafihkepjialgccenokkljdlaf

https://github.com/google/gmailsnooze

Warmly,

Robert

[lehrblogger]

A couple more ideas:

• If we publish the script so that anyone with the link can view it, and then also deploy it as a web app, users can edit the URL of the web app to end in /edit rather than /exec, and they will be redirected to the code being executed. If we explain this clearly, it's probably sufficient transparency about what code we're running with the user's Gmail credentials 🎉
• This leaves only the configuration problem. The Google Form -> Sheet idea described above might be tricky, because users would need access to the Sheet so their authenticated Ticklers could read from it, but at the same time, we don't want to expose each user's configuration to each other user.
• Alternatively, we might be able to use the Form submission to trigger a method that configured the Properties service. This feels like the most workable solution I've come up with so far, and I like the idea of using the Form to save us the hassle of building the associated UI.
• If that doesn't work, then we could tell users to have the Form submission email a copy of the answers to themselves, and then the Tickler could find that email, parse it's contents, and configure itself accordingly. This is very hacky worst-case sort of solution, but it should work.

[rosulek]

that third party might inadvertently expose my information or access tokens to others.

I'd rather avoid administering another web server/application.

What I'm proposing is to have a google-hosted web app. I think this is how @dreeves's thing works. The google infrastructure handles all the authorizations. I don't think it's even possible for such a script to exfiltrate your auth tokens -- it can only access things through the opaque GmailApp API.

This leaves only the configuration problem.

I think it really can be done as a standalone script with no Sheets etc. In the standalone script web-app you just have give a handler for doPost(e) or doGet(e). So on GET, you can serve up a configuration form populated from Properties service, then on POST you can update the key-value store in Properties. I'm not sure when I have time to try this out but I think a proof-of-concept would be possible.

users can edit the URL of the web app to end in /edit rather than /exec, and they will be redirected to the code being executed.

I think this is the right level of transparency. Power users can always install things the hard way. And actually if the edit link automatically just forks it to their own account, it's perfect!

hassle of building the associated UI

I hope it wouldn't be too involved. Famous last words.

Can we automate the Trigger creation in the Script's setup() method? That might be worth doing independent of this issue.

Yes, this could be done, independent of how things are packaged.

email a copy of the answers to themselves, and then the Tickler could find that email

Ha, that is crazy. I love it. Let us hope it does not come to this! ;)

[lehrblogger]

I thought I saw a security warning somewhere in the Google Docs about the tokens, but I can't find it. FWIW scripts do have a [getOAuthToken method](https://developers.google.com/apps-script/reference/script/script-app#getOAuthToken()), but the tokens expire after a few minutes.

I see what you mean about the web form that POSTs to the script and saves to Properties. Those requests would have to be authenticated though, and I'm not sure exactly how that would work. For what it's worth, I noticed there's also a UI for editing these directly in the below screenshot. Also independently of this issue, we could update the configuration to override the defaults there. That way we could all use the exact same code, rather than deal with the hassle of git stashing changes I don't want to commit.

I'm not entirely sure when I'll have time to mess around with this either, but I'll open issues for the other two changes now, since they'd be good starting points.

[rosulek]

Those requests would have to be authenticated though, and I'm not sure exactly how that would work.

My understanding is that it "just works" .. the web-app script is deployed selecting "execute as the user accessing the web app". Now whenever anyone POSTs, then I assume google takes care of the authentication cookies etc. From the script's point of view, using the GmailApp object and Properties object just does the right thing.

In any case, this will hopefully become clear once someone has time to try some proof of concept.