Security a data separation model

[capsprojectos]

Hi,

I don’t understand what’s the point of all this security steps in other to create a database with separation model.

In data separation model we have two or more database related. And both of them should be protected, situation which cause a big confusion for frontend user, because they must login in both of files.

This means, if you have an UI and 10 data files, the user should login 11 times.

In other to avoid this, the developer just protect one file and the others not “very well”, like Matt at ISO Magazine shows in his videos.

Shouldn’t authorization in file access be enough?

If the user have access for both files (same password and username), why doesn’t login automatically? This is related with FM doesn’t save passwords? Or just a bad thoughts for developers.

There are any solution for this, without having to buy server or other external security? Because there are small companies too...

[comment]

If the user have access for both files (same password and username), why doesn’t login automatically?

It should work as you describe.

[capsprojectos]

Yes it should work like this, but doesn’t seems to work.

I have created a start filemaker solution:

1. One file (UI)

2. Then I have clone the file (DATA)

3. After this, I created both users in data and ui files

User: Admin password: 12345

User: user1 password: 12345

4. Created the relationship between both files, authorization data and UI.

OK? It everything ok?

Now open the UI file and try to view the relationship graphs using just one password, don’t do the login in data file.

Test.zip

[supernatural]

It does login automatically. Not sure what is your problem ?

[comment]

How about this way?

Test+.zip

[Steven H. Blackwell]

Not sure what problem the original poster is experiencing here. In The Separation Model™ the Groups and Privileges are set in each file, including the UI files. The privileges in the data tables control actions on the data and to some extent on other actions such as export, etc.

This is essentially the same for the way you set up Accounts and Privileges in a file not using TSM.

Steven

[typewriter]

I usually have only a password / username on the datafile, not the UI file. The user automatically logs in as guest on the UI file, where his only privileges are: changing global fields and running scripts, nothing else basically.

This works fine for me, because the user needs to logon on the datafile only.

The only problem is IWP, because then you need to have the same username/psw on both files.

But if you have multiple datafiles, you need to maintain passwords on all of these files, don't you?

HE

[Steven H. Blackwell]

No, you use External Server Authentication and manage the Accounts via FIleMaker Server.

Steven

[Mr. Scott]

So…if you can, hep me out here: I want to track the Open Directory User Name in a local UI file so that when I use the Function "Get ( AccountName ) from the UI side, that I get the same OD name used for login to the Data File.

I have a local UI file and the data file is accessed over the WAN. I cannot use External Authentication in the UI file (since it is local, not hosted by FMS - which administers EA for account privileges), so I need to enable "Guest Privileges" for entry into the UI, which will then prompt for logon to the Data File with the user's Open Directory credentials.

Here is what I think I can do to track the same account cred's in the UI file (at least the AccountName):

1. Create a landing (or hidden utility layout) page in the UI file, with a scripted login button (in the event the UI file does not reach out to the Data File).
   
2. Have a GLOBAL field in the Data File's "Accounts" table with a calculated result of "Get ( AccountName )", named ACCT.
   
3. Have another GLOBAL field that records the file path to the UI file in order to bring the ACCT data of AccountName back to the UI file.
   
4. Set Variable ( $$Acct, Accounts::ACCT )
   
5. Set Variable ( $$Back2File, Accounts::Back2FilePath )
   
6. Open File "UI App" ( $$Back2File )
   
7. Go to Layout "Accounts" // [in the UI file]
   
8. Set Field (ACCOUNT, $$Acct) // [in the UI file, but Layout tied to "Accounts" table in the Data File]
   

Yuck! Would it be easier to have the User set his/her name in the FileMaker Preferences?

Thanks in advance.

- - Scott…out

[dansmith65]

I don't understand steps 3-8. I thought your problem would be solved at step 2. Just make sure your global ACCT field is unstored.

You should be able to access that field from the UI file to get the current logged in users account, as logged into the data file. (I haven't tested this, but I think that's how it will work)

Alternatively, you could have a script in the data file set Get( AccountName ) to a global text field in the data file, when the data file opens (or when a user re-logs in).