First attempt at security but failing miserably

I upgraded from Starter to Core earlier today.

My first app is really simple – that’s what I thought. I have two tables: Activities and Managers. I’m a Manager, and as such I have full CRUD access to Activities. However, if a non-Manager should log in, I want them to have read-only access to Activities and no access to the Manager view. Sounds simple enough. Now the problem…

As the lone Manager, I’m in need of a vacation. So as I prepare for my trip, I log into my app and add a second Manager named Joe. When I log out, I mistakenly leave my device in the Manager view. My colleague Jane takes ownership of my mobile device as I leave. Jane is not a Manager. When she logs in she sees the two manager records and has CRUD control even though I explicit told AppSheet to only display the Manager view to people who are managers. Sure, the Manager button disappears on the bottom menu when Jane logs in, but she still sees the Manager records and is able to modify them.

I am doing this in the Editor’s emulator by changing the “Preview App as”.

Also, may I ask, why does AppSheet insist on automatically creating Views for tables? I work with Slices, but when I delete the Table views, AppSheet puts them back in.

Thanks for any help,
Brian

This is a great example of how simply hiding something from view is not the same as actually securing it.

Since Appsheet remembers which view you were at the last time you were in the app, it will load that view up, no matter what. A View’s Show_if does not stop the View from rendering, it just stops the View from showing up in the navigation.

I would call the sharing of a device your first misstep in regards to security, but I’ll assume you have good reason and won’t be persuaded against that. What that means, in such a case, is that you also have to secure the data and data access. That means utilizing Security Filters and Access Modes.

For convenience. You can set them to “Do not display” if you don’t ever use them.

3 Likes

Hi Marc,

I’ve tried that already. AS won;t let me set a security filter on the Managers table. It says:
Table ‘Managers’ has an invalid security filter ‘=IN(USEREMAIL(), Managers[Email])’. The filter expression cannot reference the table being filtered.

Thanks,
Brian

A Security Filter determines which records load from a Table. You can’t run a Security Filter using data from the same Table. You’d have to keep your manager emails in a different Table.

2 Likes

I’d recommend using the user’s entry in the app editor (In Users >> Users >> Users) to identify the “managers”:

Give managers the Admin role, then you can use USERROLE() in your security filters.

Only users with access to the app editor and permission to change the app configuration there will be able to see, add, remove, or change those user entries.

1 Like

Thank you, Steve.

I’m trying USERROLE now. I made up a Gmail account and added it to the User pane as role: User. But when “Preview app as…” for that user, the reported role is Admin. Can’t this be tested in this manner?

Brian

Nope. Preview App as only changes what USEREMAIL() returns; it has no effect on USERROLE(). It’s an imperfect tool.

2 Likes

OK, thanks.

I used two real Gmail accounts and assigned one as Admin and the other as Role. I used the browser link to the app. It works!

Thanks gentlemen,
Brian

1 Like