Preview As allows users to be added which are NOT in White/Allow List

[Lucinda_Mason]

In testing I added a user in the Preview As which was not in my White/Allow List or the User table of my app. The App allowed them to be added to my User table which should NOT happen if they are not on the White/Allow List.

Is this due to the inconsistencies we see with the Preview As, where it sometimes see the User behind the scene as the actual logged in to AppSheet user and NOT the Preview As?

I’m trying to see what happens when someone who is not on the White/Allow List tries to get into my app.

[Steve]

Lucinda_Mason:

which should NOT happen if they are not on the White/Allow List.

The allow list in the app editor controls who can sign-into the app and can be used to assign roles to signed-in users. This allow list has no effect whatsoever (to my knowledge and expectation) on the behavior of the app unless you design the app to use the information the allow list provides (via USEREMAIL() and USERROLE()). If the Preview As feature enforced the allow list, you’d have to give the user access before you could test the app against their user.

[Lucinda_Mason]

Just to be clear, when I add users via the add User Emails, as seen in screenshot …

Only those users who have been added can actually log into my app? Correct?

Then, since I added a register page, they have to complete that to be added to my app. I use: IN(USEREMAIL(),USERS[USER_EMAIL]) to make sure a user that isn’t in my Users table can’t see anything but the registration form.

The Preview As doesn’t care if an email is in the Allow List? But then the App takes over and forces that unregistered user to go through the registration form.

[Steve]

Lucinda_Mason:

Only those users who have been added can actually log into my app? Correct?

Your app must require sign-in:

In the image above, note also the Allow all signed in users option. If OFF (as shown), then only those users listed in the allow list may use your app.

Lucinda_Mason:

Then, since I added a register page, they have to complete that to be added to my app. I use: IN(USEREMAIL(),USERS[USER_EMAIL]) to make sure a user that isn’t in my Users table can’t see anything but the registration form.

That is a legitimate approach to hiding views, sure. It does not prevent a skilled user from accessing hidden views, though. Nor does it prevent data you don’t want the user to see from reaching the user’s device.

Lucinda_Mason:

The Preview As doesn’t care if an email is in the Allow List?

I do not believe Preview As considers the allow list at all.

Lucinda_Mason:

But then the App takes over and forces that unregistered user to go through the registration form.

If your app is designed to do that, yes.

[Lucinda_Mason]

Yes, I have Require User Sign In ON and Allow all signed in users OFF. Thanks for pointing those out. I knew I had them set but couldn’t remember where.

Steve, How can a skilled user that is NOT in my Allow List, access hidden views? I assume it is in the browser version?
That is a legitimate approach to hiding views, sure. It does not prevent a skilled user from accessing hidden views, though. Nor does it prevent data you don’t want the user to see from reaching the user’s device.

I am currently working on Security Filters to limit data downloaded.

[Steve]

Lucinda_Mason:

How can a skilled user that is NOT in my Allow List, access hidden views? I assume it is in the browser version?

To clarify…

• If your app requires sign-in, a user that is not signed-in cannot see anything in your app.

• If your app requires sign-in and does not allow all signed-in users, a user that is not in your allow list cannot see anything in your app.

If a user is allowed into your app, that user can enter a URL into their browser to access you app. That URL can directly reference any view in your app, or even target specific tables and rows without regard to views. Doing so bypasses all navigation the app presents and sidesteps any Show if constraints placed on views.

[MultiTech]

Steve:

If a user is allowed into your app, that user can enter a URL into their browser to access you app.

True, you can hack the hell out of it - but you have to know what to put in order for it to work. If your table names make sense, people will be able to suss them out eventually; then, like Steve said, someone could hack the URL and access a root table view and see all the records for that table.

[Lucinda_Mason]

Thanks for the reassurance. I used the Incognito window tip to see how it really looks to a user not on my Allow List.

Thanks for the detailed explanation. That must be why you have stated multiple times that app info should be hidden on the URL.

[MultiTech]

Just thought I would chime in here @Lucinda_Mason.

That “Preview as” function inside the editor isn’t really a TRUE representation of what the experience will be like when using the app as that email.

Some things kinda get confused as to who you are; it sees the email you’ve entered, but it also sees the email you’ve used to log into the editor - and it doesn’t quite know how to handle it.

---

The best approach for testing your app as if from another perspective, is to actually go that route.

Thankfully, it’s super easy to create an incognito window and log into your app using the credentials you want.

[Lucinda_Mason]

Thanks for the tip. I’ve never used an incognito window so I’ll look into that.

Wow. Incognito is cool. Thanks for pointing me to it.

[MultiTech]

You’re welcome.

The “Preview As” is really helpful, but sometimes it just get’s confused.