Hi all,
I want my app to remain non public given sensitive data in it, and therefore it needs to identify who is logged in to have my security filters applied. However, I want to enable the app to be visible to public so they can click on register/Sign up (even with SSO based on their google account) to access the features, without having me to go and manually give them access via adding their email as new account or via custom login.
Is that capability available or coming soon?
I have to admit that this is a major blocker for scaling up my app.
I agree that this is a hurdle for many applications I would like to build and attract more external users…
I do beleive there should be a mechanism built into appsheet to allow “Visitors” to land on a sign on screen. This can then allow us to capture further sign on details and then send that users some interaction until adding them to an authorized list of sorts which then allows them into their real data and we can charge them and get charged by appsheet for that user…
We can attract so many customers and this would be huge growth for Appsheet revenue. We just need a way to deal with unregistered users from a public facing perspective until on-boarding them as paying clients.
We do not want to handle the passwords or user verification, this can stay on googles end but at least are hopeful to allow us a way to have an more versatile allowed user list mechanism on our end and how to handle a user not on the allowed list (direct to sign on screen).
Hi Denzil,
Thanks for the great input.
I agree, I sent exactly a feedback with the same comment about Appsheet visitor capability and revenue growth potential.
Cheers,
Allow access to the public, require login, match login against authorized users table, tailor security filters according to presence in the authorized users table.
Hi Steve,
Thank you for stepping in here..
Is this scenario already possible.
My head gets a headache and still doesn’t seem to wrap itself around a Public app scenario and if it retains all security filter capabilities.
If I ticked “Yes, this Is a public app”, in description it says that I acknowledge that security and access control is NOT required for all the data in this app OR that you will maintain correctly configured security FILTERS for all data in this app.
Does this setup allow using USEREMAIL() in security filters to see who is logged in and as mentioned use it to control table data returned to logged in user?
I would also need to deploy as a public license and not from a usual Core license?
Do forgive me for these questions or if I misunderstood something in their documentation.
Here’s a way to approach it:
- Require sign-in.
- Allow all authentication providers.
- Allow all signed-in users.
- Create a
User
table that identifies the email addresses (as would be given byUSEREMAIL()
) of known users. - Add security filters to all sensitive tables that only evaluate to
TRUE
ifUSEREMAIL()
is in theUser
table. E.g.,IN(USEREMAIL(), User[Email])
.
There are more details to handle, but this is the basic setup.
If the app allows signed-in users, you can use USEREMAIL()
.
I don’t know what this is. License questions shoul go to Support.
Thank you… I will most definitly try this setup. I recall other chats around this topic and will ask support if I can run this scenario on Core License plan..
Regarding the below, if i understood correctly this would violate TOS if I handle sign in myself on a public plan trying to falsely secure data and end up avoiding paying for each user…
Keeping allow sign in on all users is fundamental to keeping each user payable in line with TOS.
To the best of my understanding, yes. I don’t work for Google so I can’t say for sure. Ask Support for an official answer.