A new approach for limiting access to a part of a Web App

[Stefano Lista]

Goodmorning everyone,

I've noticed that several Google Apps Script users are looking for a secure way to restrict access to their Web App. In my case I am looking for a way to let everyone have access to some functions of the web app, while a control panel must be reserved for the administrator (me).

I wanted to share my approach that makes use of the novelty introduced in GAS on March 15, 2021. The release notes say: "You can now have more than one active deployment.". So I thought about this approach. I activate two deployments:

1. PUBLIC WEB APP: executed by me, anyone can access. This is the public web app and will have its own URL.
2. PRIVATE WEB APP: executed by me, only me can access. This is the private web app and only my Google Mail has access to it.

I then use ScriptApp.getService().GetUrl() to address the doGet() call. doGet() reads which Web App is running and compare the value with two fields of a sheet ("private web app" and "public web app", I store these values into PropertiesService.getUserProperties()).

IF the active web app (ScriptApp.getService().GetUrl()) is equal to the Public Web App, THEN doGet() executes a function that show public content, OTHERWISE IF it is equal to the Private Web App Url THEN it executes the function that shows private information only to Apps Script Owner (me).

I tested the whole process and it seems to work. What do you think? Could this be a good approach? Is it a safe method?

[Alan Wells]

It's intriguing to think about how to use the new deployment capabilities.

I think it's a great idea, because your public Web App is published to be accessible to anyone, and therefore there is no way to know who the current user is by using the "getActiveUser" or "getEffectiveUser" methods.

So what you've done is come up with a way to restrict access without requiring users to log in.

And you haven't created a hidden "backdoor" in the UI which someone could find if they inspected the HTML.

Nice.  I think it will work.

[dimud...@gmail.com]

Support for multiple active deployments have been around for a while, even before the V8 update.

Your approach is viable, I've done something similar, creating multiple deployments, with a "root" deployment that "routes" to one of several other deployments depending on context. 

If you need extra security its possible to create multiple manifest files, one for each deployment.

That way you can have more fine-grained control over the permissions (set via OAuth scopes) granted to users of a given deployment. 

There is no option in the IDE to create a new manifest file,  so you have to make a copy of the appsscript.json file and then rename it.
What's more, you have to create the new deployment using the Apps Script API as there is no option to select a custom manifest from the Apps Script IDE (but it can be done from the create endpoint in the Apps Script REST API). Just remember to exclude the .json extension when referencing manifest names in the request body.

[Adam Morris]

Really fascinating thread!

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/0cff0612-f578-4b33-a98f-9a348b1e9a13n%40googlegroups.com.

[Kim Nilsson]

Yes, bookmarked! :-)

torsdag 8 april 2021 kl. 06:32:41 UTC+2 skrev Adam Morris:

Really fascinating thread!