Pitfall in using global script variables in your security model

[TheTominator]

This may be old news to some of you, but it took me a while to

realize it. Global script variables may be fully accessible to

the users for both reading and writing.

Even in a locked down solution, a normal user with data entry

privileges can read or modify the value of global script variables.

The only thing required is access to the calculation engine and

the Let() function.

One easy way is to use Replace Field Contents with Replace with

calculated result. Read the contents or assign to the global

variable in the variable assignment of Let().

I was planning on using a global variable (e.g. $$isLicensed ) in a

FileMaker runtime solution to keep track of whether or not the user

has properly satisfied the requirements of running my solution in

the full, normal mode instead of a demonstration mode.

This would let me run the license mode check on startup or any

time the user wants to edit the license code information.

In my situation the license code is keyed to the user's personal

information (name, company) displayed on the home screen.

I'm not stopping piracy, but making it so that the pirates

(or clueless users sharing the solution) are always reminded that

it is a pirated copy.

I thought this cross-table convenience was handy and secure enough

until I realized that the user can alter the contents of this global

field directly by themselves at any time. Thus the only security it

provides is security through obscurity.

It may be possible to restrict all access to the Let() function by

disabling access to Replace Field Contents, but I like the added

power it gives to my advanced users to manipulate their data or

correct data entry mistakes.

[Steven H. Blackwell]

Even in a locked down solution, a normal user with data entry

privileges can read or modify the value of global script variables.

And such users can access a lot of other items as well. You might want to look at this article in FM Forums.

Additionally, there is the matter of the Data Viewer.

Generally speaking, the UI is not part of the security schema, although it's a good idea to lock it down.

Steven

[TheTominator]

Additionally, there is the matter of the Data Viewer.

Unless I am missing an attack vector here, the Data Viewer will refuse to display any info from a database file unless you have administrative access to it. By "locked down solution" I mean that a runtime file is created with the admin account removed.

Thank you for providing the link to the older post.

[Steven H. Blackwell]

the Data Viewer will refuse to display any info from a database file unless you have administrative access to it

Yes that's generally correct. However there are circumstances, unusual to be sure, where defined variables can persist in the Data viewer Watch window and be refreshed.

Basically, however, the key point here is not to rely on the UI for security purposes.

Steven