How to Trigger a Forced App SYNC on All Devices (device_id based access control)

AppSheet AppSheet Q&A
, ,
1

Hi everyone,

I have an AppSheet application where I store device_ids in a table. If a row in that table is deleted, I want the corresponding device (with that device_id) to be blocked from using the app.

In practice, users can still navigate the app until they refresh/SYNC the app , but after SYNC they can’t see any data. I’m trying to add a stronger security measure.

AppSheet updates automatically at some interval (e.g., every ~30 minutes). Is it possible to trigger a forced/reload refresh from within the app using a command so that all devices running the app immediately perform an automatic forced update?

For example: suppose you “fire” someone. How can I instantly revoke access to the app on their device using device_id tracking—i.e., make their access stop immediately when the device_id row is removed?

Thanks in advance!

6 Likes
2

Nope.

4 Likes
4

First of all, thank you.

What you mentioned sounds like it would mean that the user who has that specific device_id could still perform at least one action (add,update or delete) in the app within the next 30 minutes, right? And If it performs such an operation using a row that has actually been deleted but not yet updated, would the application run into a synchronization error?

Also, if the user signs in with their Google account, and then I remove/disable that Google account from appsheet users, wouldn’t they still be able to browse inside the app until AppSheet synchronizes again? Do you have any recommendations for how to block a user/device instantly (for immediate access revocation)? Would undeploying and redeploying the application provide any benefit?

And, is there a feature in AppSheet that prevents users from taking screenshots on the mobile app?”

3 Likes
5

Once the user has the data on their device, assume they can do anything they want with any of it, regardless of how you’ve configured it. A savvy user can do anything they want with it. This is why security filters are so very important: properly used, they keep the data the user should never have from getting to their device.

The AppSheet model is distributed: each user’s device receives and uses its own copy of the data. Changes on either end, the user’s device or the server, are periodically synchronized with the other. Until that sync happens, the user’s device will behave according to the configuration it received at the last sync. There is no way to force a sync from the server to the user’s device.

The user can prevent a sync by simply turning off the network of their device. Even without networking, many, most, or even all of your app’s features (depending on how you have it configured) will continue to work just fine, indefinitely. So if the user has sensitive data on their device, they can keep it there indefinitely, and there’s nothing you can do.

I don’t know what would happen exactly if you disable the user’s Google account (or whatever account they use to access the app). But if they’ve turned off networking, disabling their account would definitely not have an effect, not immediately, possibly not at all. The effect of disabling the account depends on how AppSheet integrates with the authentication providers, there are many variables, and I just don’t know how it’s all setup.

Your best bet to prevent the user from taking malicious action is on the server side. When a sync occurs, the data exchange is governed by the server, and the server will always have the most up-to-date data. If the server data says the user has no access, the inbound data can be refused, and the outbound data withheld–if you’ve configured it all properly.

Good practices:

  • Require login.
  • Allow only authorized logins.
  • Use security filters to withhold rows the user should never see.
  • Keep more-sensitive and less-sensitive columns in separate tables (that can then have separate security filters).
  • Use Are updates allowed? on tables to control the user’s access. These also apply on the server, and can prevent client-side updates from reaching the server if properly configured.
  • Understand that NONE of the following offers actual security: slices, Show?, Initial value, Editable?, Reset on edit?, Display name, Description, Only if this condition is true, or anything else applied on the client side.
  • Enable device-side encryption. It’s not perfect, but it definitely raises the bar significantly.
  • Enable secure file and image access.

True security only happens on the server. Design with that in mind.

11 Likes
6

I agree with @Steve 100%.

It is also worth noting that even white-listed users are not immune to this issue. It will take up to several minutes to disable their access…provided they remain connected.

No, there is no way to prevent this from AppSheet.

It sounds like you need an extremely secure app that houses sensitive data and provide more control over device side actions. It may be that AppSheet is not the correct tool for your needs.

4 Likes
8

image
image1014×167 9.66 KB

Thank you for your interest.

In the tables, I’m currently using security filters of this kind. When you say “Require login,” do you mean a form that prompts for a password during entry? If by ‘require login’ you mean this, could you please explain a bit more. In my case, there is no login page in the app.

Maybe it could work like this: if I validate using a password in a virtual column, then when the device is not synced, could the app still fetch and use the password stored in that virtual column?

Right now, my app only accepts authorized logins.

Also, as far as I understand: regardless of which security filter is used, all tables in the app’s data source are still delivered to every device/app user. However, depending on the security filters, not everyone can actually view all data.

So, depending on the security filter, a user whose authorization has been revoked on the server side could potentially still see the latest data while the device has not synchronized yet. But I’m not sure what the exact behavior is when performing an add, delete, or any other action.

When I trigger an action in the app, does the device first sync with the server and then perform the action? Or does the app send the action command to the server first, and then synchronization happens afterwards? I didn’t fully understand this flow.

Also, I assume that data from virtual columns is fetched from the server. So I was wondering: do we need to include a virtual-column-based value inside the security filters as well? That’s what I was thinking about.

I’m going to try a few things.

1 Like
9

In my second question, I actually meant white-listed users. I think the application creator should be able to send forced synchronization to all users when needed. For this kind of scenario, there shouldn’t be a requirement to wait 3 minutes, 5 minutes, or even half an hour.

I asked about the screenshot question just out of curiosity, so it isn’t that critical for my application. I was thinking about whether it’s possible to prevent a user who has been terminated from extracting customer information. I’m only evaluating potential security risks :slight_smile:

2 Likes
10

image
image1011×516 46.2 KB

I also didn’t understand the access mode and the shared part here. What are the differences between the available options?”

2 Likes
11

For access mode, I beleive it logs the edits as either coming from the App creators email address or from the logged in users email address “Useremail() “. This is at datasource level. As the app creator, all reads, writes and bots allow Appsheet to use Creators credentials for access to data.

As app user, all reads, writes and bots from Appsheet are to use the identity of logged in users credentials. They will then obviously need shared access to the datasource outside of appsheet.

3 Likes
12

Shared I beleive if unticked creates Private tables. Meaning a copy of the template datasource table is kept with the apps definition. Requires sign in is mandatory.

Meaning each user that logs in gets a copy of the datasource on their own cloud identity and the table is not shared anymore.

Note that you definitly do not want to edit columns or change datasource things once finalized.

4 Likes
13

I think you may be missing a fundamental aspect of AppSheet apps: the app works exclusively on data stored on the user’s device itself. Only when a sync occurs does the app interact with the server, and the app’s involvement is limited to sending the changes the user’s made to the server, then fetching the updated data from the server. You might find this support doc helpful:

5 Likes
14

Thank you Steve

2 Likes
15

Extra insights

1 Like
16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.