The security risk of Publisher Pro plan

[R_S]

Hi there, I am concerned about the security problem in Publisher Pro Plan when you achieve the following behavior. This is because the official document says "If you deploy an app on a Publisher Pro plan, you should assume that all the data in the app is visible to anybody ".
What we want to do is share a spreadsheet between the two apps and process the data collected in the Publisher Pro plan app on the Pro plan app. To do this, we will take the following steps.

1. The user enters values in the Publisher Pro plan app.
2. The entered values are stored in the shared google spreadsheet.
3. In the SECURITY of Table settings, turn on the “Filter out all existing rows” setting so that users cannot see the values entered from the app.

In this case, is it correct to say that the security is maintained because the entered data is not visible to the user?

[Aleksi · Accepted solution]

Yes your assumption is correct. When that option is ON, the data is filtered on the Appsheet server and no data is downloaded to your app user’s device.

[R_S]

Thank you very much! It helps me a lot!

[Aleksi]

You’re welcome

[Dario]

Hi Aleksi, re: this thread unfortunately the 'Filter out all existing rows" invalidates lookup expressions (and even linktofilteredview ones). Do you know of a method to keep this filter active but still lookup the data in some way using an expression?

The reason I’m asking is because I have a workflow rule that is triggering an email to a person from a mailing list (via lookup expression). If my mailing list is set to ‘filter out all existing rows’ though, the workflow rule will not trigger. I tested the workflow and it gives me the following error.

This workflow rule is critical to an OTP system that I am utilizing in the app, it would be great if there was an expression that could work around it somewhat so I could still keep my mailing list private.

[LeventK]

@Dario
Have you tried with enabling Bypass security filters option inside the workflow rule?

[Dario]

Thanks for the suggestion LeventK. Seems like it should work, but no luck unfortunately, still getting the same error message when testing.

[LeventK]

@Dario
Can you post a screenshot showing how have you set those To, Cc and Bcc fields inside your workflow rule?

[Dario]

Sure thing. I know its a problem with the “Filter out all existing rows” toggle because when I turn it off the workflow runs fine.

[Steve]

The Filter out all existing rows option is strictly for write-only data: the data cannot be used by the app at all. You can use the data from another app, though, if you wanted to.

To be able to use the data from a workflow or report of the same app, you’ll need to use a security filter of FALSE in combination with the Bypass security filters option rather than Filter out all existing rows.

[Dario]

Thanks for the reply Steve. Is the ‘FALSE’ tag going to be functional for a Publisher Pro App though? I thought it was just a feature for pay-per-user subscription tiers.

[Steve]

That I don’t know. I’m really not familiar with the paid plans at all.

[LeventK]

Can you try with changing the LOOKUP() expression with this and give it a try?
LOOKUP([_THISROW].[Player],"Playermail","Players","ReturnColumnName")

[Dario]

LeventK:

LOOKUP([_THISROW].[Player],"Playermail","Players","ReturnColumnName")

If this works I’m gonna be so happy Levent.

Edit: No luck, same error as before : (

P.S I tried the same workflow but switching it to a ‘Filter out existing rows’ on my parent table, as the example I provided has the filter on a child table. No luck though, it gives me the same error, so I don’t think it has to do with the parent / child relationship.

[LeventK]

When you test the expression in TO property, is it returning a value or is it returning a blank value?

[Dario]

Works perfectly fine, even if the filter rule is on.

[Aleksi]

“Filter out all existing rows” doesn’t work with the “ByPass” option. You need to use Security filter but that doesn’t work with Publisher Pro plan… not even with a “False”.

[Dario]

Is there no workaround? I saw tsuji_koichi post something but I havent dug deep into the details.

I appreciate the feedback guys, my last question is, how difficult is it for someone to see the contents of my table in a public app through browser based tools? I was on Firefox earlier and pulled up the tools, but couldn’t find any table information in HTML tags or anywhere I looked. Is it something where you need specialized scripts / hacking tools to get the table data from hidden slices in an app? Also If I whitelist my publisher pro app would it give me more security than if I just distributed it to users via standard URL links?

[Aleksi]

No workaround.

It’s not so difficult because you can play with the URL. Whitelisting doesn’t change this situation because the URL is still available. When the app is public, it’s totally public and it’s data as well.

[Dario]

I was playing around with the URL tags a bit now, and what I noticed is that Virtual Columns are not searchable in the HTML tags when they are not set to ‘show’. Also, correct me if I’m wrong Aleksi, but wouldn’t a table that has no view or reference in active views also be inaccessible unless someone knew the exact table name? I’m just imagining a situation where a form writes information into a spreadsheet that exists with no active views or references aside from that form entry.

Thanks for your feedback, this is all very interesting to me, I guess that’s why we are all here right? Passion for this wonderful platform called Appsheet : )

[Steve]

Dario:

I’m just imagining a situation where a form writes information into a spreadsheet that exists with no active views or references aside from that form entry.

Every table configured in your app has at least a detail view. If the table is not explicitly read-only, it also has a form view. There is also a way to get other views even if they aren’t configured.

If the data is on the device, assume the user can get to it. It may be difficult, but it’s possible.