The most basic security feature is user sign-in.
When to require user sign-in
Require user sign-in if your app:
Has any confidential data.
Needs to distinguish between users in a secure and reliable way.
There are five levels of security afforded to apps that require users to sign-in:
Requiring sign-in with a specific provider
Only users with an account hosted by a specific provider (such as, Google, Dropbox, or Office365) can access the app.
Specifying a user-allow list
Only users explicitly listed in an allow list can access the app. You can learn more about granting application access and revoking it. One approach to this is using domain groups, which you can learn about here.
Utilizing security filters
The app can be configured to show different subsets of data to different users.
Using expression logic within the app based on the
USERNAME()functions to customize the app on a per-user basis.
The app can explicitly capture the identity of each user who makes a change to the app. Additionally, the audit history automatically captures the identity of every user who interacts with the app.
Note: None of the security mechanisms described above are available to apps that disable the user sign-in feature.
Which subscription plans support user sign-in?
AppSheet provides five different plans: Starter, Core, Enterprise Standard, Enterprise Plus, and Publisher Pro. Only Starter, Core, Enterprise Standard and Enterprise Plus plans support user sign-in. Publisher Pro only supports creation of publicly accessible applications that don't contain sensitive data and don't require sign-in.
If your app's data is sensitive, then you should require sign-in, and therefore sign up for the Starter, Core, and Enterprise subscriptions.
How public is an app on a Publisher Pro plan?
If you deploy an app on a Publisher Pro plan, you should assume that all the data in the app is visible to anybody. Furthermore, you should assume that anybody who wants can run the app. If the app permits data changes, then anybody can make those changes.
Can I secure an app without making user sign-in?
This question comes up occasionally from app creators who want to use one of the public Publisher plans. The answer is no.
Some app creators try to create their own workarounds for each of these levels of security. However, these approaches all have their shortcomings.
Instead of an allow list, can I control distribution of the app install link?
While this is possible initially when the app creator sends the install link to users, there is no way to control whether the link is forwarded. Anybody with the link has access to the app.
We have had multiple instances where an employee of a company has access to the app and then that person leaves the company. At this point, the company requests us to disable access and there is no way to do this.
If the link is ever placed on a publicly accessible site, it may be crawled by a search engine. And the content of the app (the data shown in the app) could also be indexed by the search engine. This is because the intent for Publisher Pro apps is to have broad public access to the app.
2. Can slices be used instead of a security filter?
Slices are a mechanism used to define virtual tables. Even if the user was identified and used in the filter condition of a Slice, this doesn't guarantee that the entire data set isn't accessible as well.
When the app is opened in a browser, all of the data used by the app is accessible to anyone who opens the developer console and examines the data of the running application. There is no guarantee that the entire table isn't available even if a slice is defined on that table. The only way to ensure this is to use a security filter for the table.
3. Can I create my own username/password mechanism?
Not really. If you want to implement your own security, you need to worry about authentication (is the person who they claim they are), and a secure implementation (encrypted capture, transmission, and storage of passwords, as well as mechanisms to handle forgotten passwords, revocation, and so on). This is a huge and complex undertaking. In fact, this is why AppSheet does not provide its own username and password mechanism. Instead, we utilize third party authentication via highly credible providers like Google, Dropbox, and Office365.
4. Can I verbally tell people to sign-in and use expressions with
USEREMAIL() to control app behavior?
USERNAME() do not have a defined value if the app does not enforce user sign-in. The Login option in the app menu will also only be visible for apps that require sign-in. Apps should either assume all users are signed in, or assume that no users are signed in.
Alternatives to requiring sign-in
For reasons of cost, some app creators may want to stay with a Publisher Pro plan. We want to emphasize that these apps are inherently insecure. However, if the main goal is to acquire the user's email address rather than data/app security, here are some aspects of the functionality that can still be achieved:
In forms, instead of using
USEREMAIL()to automatically fill in a column value, the user can explicitly type in their email address. This will not be verified, but an email can still be captured and used.
The app can utilize the UserSettings feature to ask the user to provide their email address. The benefit of this approach is that the email address is typed in once and then can be used in formulas (for example,
UserSettings("MyEmail")). This email is not authenticated (any user could claim to be firstname.lastname@example.org), so this is not a security mechanism.
If you have a fixed list of users in a Lookup table, you could assign each user an ID and ask them to provide their ID via the UserSettings feature. This ID can be used with the Lookup table. Note that this is not a password. It is not encrypted and all users will have access to the Lookup table, so this approach is in some ways even less secure than the other options.
guest_-956001730 user accessing my app?
You may see
guest_-956001730 in your log files even if your app requires sign-in. This system user account is used to log system events, and is not an indication that your app security has been compromised.
This system user account does not count towards your active users.
Note: In the future, system events will be tracked using the
AppSheet System User account.