Privileges in Interface file

[TJ53]

Hi,

With the separation model, I assume that the accounts and access privileges are defined in the data file.

But ... I guess that you also have to create a privilege in the interface file so the users cannot edit the scripts, the relationships graph, etc., right?

What's a good way to deal with this? the file is configured so when it opens it automatically logs in with a common "user" account for everyone?

Thanks in advance!

[T-Square]

Personally, I have my Interface file locked down, and all users on this file are automatically logged in as "DBUser", which is en extremely limited account. I have the same privilege set in the data file, but there it has nearly full access, to give my clients full control over their own data. (Well, I limit access to a few administrative/configuration fields, scripting, and database design)...

I'll note that my user base does not require individual privilege sets, and so I don't have to manage them much beyond "Yes" or "No."

HTH,

David

[aholtzapfel]

I do this too except I have multiple prevledge sets.

In the Data File, the user needs the correct field level privledges (running a script in the interface file with "run with full access" option will NOT give full access to data)There are not any avilable layouts to them and this file is never shown in a window.

In the interface file, pay close attention to everything, Layouts/scripts need to be based on the user's privledge set. (Again, Run with full access option will NOT give user full access to data in the data file)

The Seperation model does have many advantages but can make security more challenging.

[TJ53]

Thanks a lot for your tips! (sorry I thought I had replied to this already ...)

[Greg Hains]

Hi.

I am going through this same process now and have a question along the same lines.

I have split my UI and DATA files so that I can distribute a new UI file to users as it's updated, their DATA file staying where it is.

Is there anyway that I can implement security in such a way that I can, say, sign into their environment, add a new user into the DATA file, without having to distribute a new UI file to all users?

I see the dbUser example above, and that can link the two files transparently, but can it be done so that a login script (from the UI file) is invoked that then determines the correct level of access to the data file?

Sure beats having to distribute new UI files each time there is a security change in the database.

Cheers,

Greg

[dansmith65]

I've been trying to figure out how to manage Privileges using Separation Model as well. Reading this post just gave me a new idea...

You could automatically log the user into the Interface file as T-Square mentioned, then make the user login to the Data file, via FileMaker security. This would centralize Privilege management, as the Interface file only needs one account for all users.

This does raise two issues:

1) using get(accountname) from Interface file will return the same value for everyone. (this can be remedied by setting the account name to a global variable or field in the Interface file at login)

2) File > Change Password will not work, unless they are in the Data file when they do this. (this can be remedied by using a custom menu and a script to script, or two)

[dansmith65]

I've been implementing the above method in a solution I am working on, and have come up with a list of security vulnerabilities it introduces:

Items from Interface file that can be viewed by anyone who has access to the file:

• tables/data stored in Interface file
  
• ESS tables (instead, put it in the Data file, then let the Interface file get it from there)
  
• custom value lists (if a value list get's data from the Data file, then it should be safe)
  
• scripts and custom functions are safe as long as the default account cannot modify scripts
  
• all Table Occurrence names created in Interface file can be viewed (cannot get to the data, but can see the names)
  

Given these vulnerabilities, this method may not be for everyone, but I'm going to keep pursuing it.