Clarifying user sign-in requirement when using USEREMAIL()
As some of you know, if you use USEREMAIL() or USERNAME() in an app that doesn’t require sign-in, we’ve started to show deprecation warnings, which will switch to errors on Jan 20th. This is fixing a loophole in our app verification logic. This path was never intended to work.
However, we recognize that a few app creators have used this unintentional loophole to “roll-their-own” app security. Broadly speaking, the approach used is: (a) do not require app sign-in, (b) inform my app users that they should log in even though the app doesn’t require it, © utilize USEREMAIL() within the app to hide or show information via expressions/slices,
For a long time, we have been emphasizing what a bad idea this is. There is even an explicit checkbox in the app definition that requires the app creator to certify that they have read the security article explaining why it is a bad idea. I have updated this article to further clarify why this is a bad idea from a security point of view. https://help.appsheet.com/security/user-access-control/require-sign-in-the-essentials. The article also has a few suggestions of things you actually can do without requiring user sign-in.
In most of these cases, the primary motivating factor is the low cost of the public plans and a willingness to trade-off app security for the lower cost. I understand and empathize. It is natural to want the lowest-cost alternative.
As a platform provider though, we have to take security seriously. We have been in the unfortunate situation of having to talk to app creators who didn’t set up security, had a user leave their organization after a dispute and mess with their data. We’ve also seen app creators try to use slice filtering to roll their own security. Anyone with basic knowledge of a browser can break this kind of “security” and see all the data behind it.
As a business, security and user sign-in are in fact the primary distinguishing factor between our public plans and our secure plans. The secure plans cost more because they add more value to a business customer, and that is what we monetize. I suppose we could have chosen to differentiate and monetize on a different feature axis. However, this is the choice we made more than two years ago, it works for most of our customers and we have been transparent about this.
For the customers currently on a public plan but using the USEREMAIL() feature, please send us an email (support@appsheet.com) with the following info:
-
who is using your app? members of your team or members of the general public?
-
what do you use USEREMAIL() for? is it just to capture user identity in input forms, or is it also in condition logic?
-
do you show different data or views or actions to different users based on USEREMAIL()?
-
how many unique users do you have per month?
You’ll need to use a Secure plan, but we’ll figure out how to get you onto the least expensive Secure plan that can work for your app.
LinkedIn
Twitter
