conflicting description in appsheet help and some other questions related to lisc.

AppSheet AppSheet Q&A
,
1

Hi All, so I had done a lot of research on the following but was unable to find a suitable answer so requesting all the experts here to guide:-

I’m making an app for customers, which have different email domain not necessarily being hosted on the sign in options provided by appsheet (like google, Microsoft, apple, dropbox, etc.) so as a workaround, I made the app public and user usersettings to make my own log in page. This allows me to define any email ID along with the password which the row filter than uses to dispaly the relevent information to each user. This has some inherent security risks which i understand but i dont want to violate any terms of service.

However in “User Settings: The Essentials” is says that Note that user settings is not a mechanism to lower licensing requirements. For example, if there are five members of a team using a deployed app, we still requires five user licenses. It is inappropriate to share a single user sign-in account across multiple users of the app, having them differentiate via user settings.

But in “Require sign-in: The Essentials” it says:-

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 bill.gates@microsoft.com), 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.

So i find this to be conflicting, are we allowed to do the later approach (having email and password stored in a table to do lookup) or not? Many of my customers may not have the domain authentication offered by appsheet.

Secondly, on the lisc. part, can we make the app public for 50$ a month and pay only for that period when we are actively using the app and make it dormant otherwise so as to save cost.

Finally, is there a way to limit the no. of users which can be logged in at any time. for example my app may be shared with 50 people but if i can limit the number of concurrent users to say 10, this will require only 10 lisc. saving cost and any next user who tries to login would have to wait.

2

There is no secure way to implement your own login system with AppSheet: any user of your app will have the potential to discover the usernames and passwords (or whatever you want to call them) of all other users. The only way to possibly secure the logins of the users is to use the authentication AppSheet provides.

The example does not suggest an email and password–it uses email as an example of an ID that could be used in a lookup table. Using USEREMAIL() avoids requiring the user enter their ID manually. I agree the wording is not as clear as it could be. Attn @lizlynch

Nope. You pay for the licenses whether they’re used or not. You’re paying for potential, not actual. That said, you could probably cancel your licenses when you don’t intend to use them, then get new licenses when you need them. Talk to your sales rep to confirm; I’m just speculating.

Not possible.

2 Likes
3

If you have a Public App - i.e. the setting “Require user signin?” is disabled or “off” - then there is no licensing at all. Your app can be used by an unlimited number of users BUT there is no mechanism to identify any of the users accessing the app. This is an UNSECURED app

When “Require user signin?” is enabled, each user MUST be authenticated through one of the supported authentications providers as stipulated by your app - either “Any Provider” or a certain specified provider such as Google, Microsoft, Apple, etc. This is a SECURED app and licensing DOES apply.

The first excerpt you referenced is referring to a SECURED app and is basically stating that you cannot expect to share a single login email address across multiple users in an attempt to reduce the number of user licenses. The identification of each user is done at the time the app is launched BEFORE any app specific logic is applied.

The second excerpt is also referring to a SECURED app but in designing the app to use ADDITIONAL emails other than the Login email address. You would not be authenticating the user based on this email address but it could be an email address to send emails or text messages to. You can build a Users table or allow the user to set a USERSETTING to capture some personal email address and this email address is NOT used to authenticate the user.

In a Public UNSECURED app, you might be tempted to build your own “Login” process but nothing can prevent each user from creating a dozen different login accounts. And due to the lack of user authentication it would be extremely easy for a user to gain access to another user account.

Lastly, user licensing is not based on the number of concurrent users. As soon as a user successfully authenticates and gains access to the app, they are counted as an active user requiring a license. For example, if you had 10 different users accessing the app each day, in a month that would be 300 active users requiring 300 licenses.

2 Likes