Deep Links and Display Criteria / Security Filters

Two parter… First I do not use the native white labeling in Appsheet. I use AWS Cognito and am rolling my own granular access security based on USEREMAIL…

If I have a deep link, say in an email, txt, or notification, that take someone to a view that I have the display condition set to NOT show it to them, will that be ignored and they will see it through a deep link anyway… Basically do deep links ignore the display criteria? (Is there anyway around this?)

If I have a deep link that takes someone to a specific record, however the security filters are set to not show them that, what happens?

Does anyone have some good easy tactics for dealing with this? My initial thought is obviously I don’t want to send people “bad” links in the first place and to “run” some form of notification relevance, but that may be difficult at scale, and i’m looking for a system double check, and keep me out of the dog house…

Solved Solved
0 10 553
1 ACCEPTED SOLUTION

MultiTech
Participant V

You might try the following:

Instead of using the regular view, let’s call it Table_View_1, you could instead create a dashboard with two views in it:

  1. Table_View_1; and
  2. A stand-in view for when nothing is shown (You could even actually make use of this page with links to other places, customized texts, actions, etc.)

If you use a conditional statement to determine which view inside the dash should be shown, based on the presence of data, then only the right view will be displayed.

Hack hack hack… all day long…

View solution in original post

10 REPLIES 10

Steve
Participant V

I believe so. Show if only affects the decision to display in a larger scope; it’s not a security mechanism.

I’d expect a blank view. The security filter prevents the app from even getting the row, so there will be no row data for the app to display.

TyAlevizos
Participant V

What Steve said. Security filters are server side so your second case should be a blank ux. If you’re not seeing that behavior I would call that a bug.

@TyAlevizos and @Steve So then the only way to “not send someone” to a view they shouldn’t be seeing is to NOT deliver the deep link to them… This is a challenge since they could have an email with a deep link forwarded to them via email by another app user… Any ideas on how to get this squared away? (Even for example deep links to entirely different app)

I agree that it’s a challenge. Over the years I’ve seen this behavior with multiple BI tools, various client server situations and numerous other software solutions… Once you introduce a transport layer like email, all bets are off on the client side and your recourse is a) require authentication to get in (SSO etc) and require authorization once you are in (AppSheet Security Filters). Both of these need to happen “server side” for the security to be effective.

Pretty much… my current plan is to just white wall them… but I t sure would be nice to get a little more elegant, and redirect them to a better app, or provide some form of message, something…

Conceptually similar…

Yes… For sure… Trying not to be that guy.

TyAlevizos
Participant V

Yeah you mean like this?

Click the vote button

@Grant_Stead How about if you add an IF statement in your workflow rule like if condition is true, show this deep link, otherwise show another one which can show fixed detail view like “no data”. If you have a formula with the security filter, you could use it with the condition as well… or with a small change.

MultiTech
Participant V

You might try the following:

Instead of using the regular view, let’s call it Table_View_1, you could instead create a dashboard with two views in it:

  1. Table_View_1; and
  2. A stand-in view for when nothing is shown (You could even actually make use of this page with links to other places, customized texts, actions, etc.)

If you use a conditional statement to determine which view inside the dash should be shown, based on the presence of data, then only the right view will be displayed.

Hack hack hack… all day long…

Top Labels in this Space