Disable layout Creation

[oleung]

Hello all,

We have built a solution using the separation model. It just comes up to my mind that users could be possible to create a new filemaker interface file themselves to access the data by defining a proper setup on using the external data source.

This could link to a security concern. I am not sure if there is some smart setup which i have missed out or it is a design limitation which could not be avoided.

Is there anyway to tighten this or can we disable users to create new layout on external data source if they do have a proper account to access the data file?

I appreciate any input here.

Thanks,

[comment]

Why is this a security concern? They can only access the data file using their account and they cannot do anything they do not have privileges for. This should cause concern only if your security is built on the layout level - which provides no security at all.

[oleung]

That's what i understand as well. So, setting the privilege right is the only way to ensure the security concern are intact and using layout or logic flow to restrict and avoid user to making unnecessary damage on data are too fragile. Is this right?

Thanks Michael,

[comment]

Yes, more or less (I wouldn't put it quite that way). Anything you do with the user interface is for the user's convenience only. For example, you can give users a popup menu to choose from - but if there's no validation on the field, you cannot be certain the field will contain only items from the value list.

[Steven H. Blackwell]

It just comes up to my mind that users could be possible to create a new filemaker interface file themselves to access the data by defining a proper setup on using the external data source.

Your concern is well placed. [color:red] An important note however: this has nothing to do with the Separation Model. It applies to traditional FileMaker Pro files as well.

They can only access the data file using their account and they cannot do anything they do not have privileges for.

You would certainly think that is the case. However that is not correct. Users can perform some interesting actions using such external UI files. We spend quite a bit of time in the FTS training dealing with this phenomenon and how to manage it.

Steven

[comment]

Are you saying that users can do things that their privilege set does NOT allow them to do, just by logging in through another file? Could you provide an example of such action?

[Steven H. Blackwell]

A number of privileges are file specific, and may not apply in other files. Some examples of this include printing and printing to PDF. Under some circumstances, this can also include exporting of data. It also includes export field contents.

If users have write privileges to tables or to fields, these actions may also occur in ways not contemplated within the UI of the original file.

Steven

[comment]

True, but they can only print/export data they are entitled to view anyway. Still, I'd be curious if there's a way to prevent this.

[Steven H. Blackwell]

I'd be curious if there's a way to prevent this.

Essentially by Record Level Access and Field Level Access only. And if a user has access, even read only, the data are still extractable.

I will have more on this soon, but this is a known issue. I have shown this at various Devcon's and Pug and Developer group meetings for the past five years at least.

Steven