Protecting Databases from being opened

[SteveB]

I'm developing a Kiosk solution (FM5 and Win98) that has 4 FM5 databases as part of the solution. How does one protect the files so that they can't be opened and examined by a copy of Filemaker that happens to be on a user's machine? I want the files to only be openable by my main file under script control (or by one of my other datafiles also under script control). If I password protect each file, how can I then open them automatically under my control without user intervention? Thanks for any suggestions. Steve

[john.daly]

Thats a whole lot of questions!!

If you set a default 'no password' for the secondary files with the same permissions as the user password on the mainfile then they will automatically open without a password prompt. You will also need to check the 'Try Default Password' in the document preferences.

(You can use the same password as in the main file but if the user changes the password in the main file that will cause a prompt for the old password when the secondary file opens and this could be confusing.)

Put a start up script in the secondary files that runs automatically and hides and locks the status bar. This will prevent anyone accessing any layouts apart from the one you allow in the start up script which should not show any fields.

When you call a script in the secondary file from the main file then your user will have access to any layouts or functions that you allow.

Hope this he;ps.

[SteveB]

quote:

---

Originally posted by john.daly:

Thats a whole lot of questions!!

If you set a default 'no password' for the secondary files with the same permissions as the user password on the mainfile then they will automatically open without a password prompt. You will also need to check the 'Try Default Password' in the document preferences.

(You can use the same password as in the main file but if the user changes the password in the main file that will cause a prompt for the old password when the secondary file opens and this could be confusing.)

Put a start up script in the secondary files that runs automatically and hides and locks the status bar. This will prevent anyone accessing any layouts apart from the one you allow in the start up script which should not show any fields.

When you call a script in the secondary file from the main file then your user will have access to any layouts or functions that you allow.

Hope this he;ps.

---

The seconary files should open without splash screens, so that the files integrate seamlessly. This is a single user solution, so that I don't believe I want passwords at all. If I have to employ them to protect the other files, I will, but the password(s) will be mine, not the user's and should be transparent to him. Given the above what can I do to prevent someone with a copy of FM from getting into one of the files?

[George]

If the single user is using a Windows 2000 pro machine, you could setup EFS (encrypting file system) on the machine's folder that has the data files so that the local user has the key for the file. EFS will open the encrypted file automatically and then re-encrypt it when the file closes. If the file is removed from the machine it stays encrypted.

[john.daly]

I refer back to my previous reply. As far as I'm aware the splash screen will only show when the main file is opened. The user does need to even be aware that the files are password protected and if they can't change the password then you just need to use the same password on the secondary files as the main file. In Document Preferences, for each file, set Try Default Password to be the password for the user. The files will then open without prompting for the password. Your own password would allow access to the whole file whilst the User password woul not.

[Chris Wood]

Dont forget that if a file is opening with a default password, you gain access with your "developer" password (that allows access to all functions and controls) by holding down the Shift key while double clicking the file icon.

[This message has been edited by Chris Wood (edited March 14, 2001).]