Security Problems in multi-user mode

[fperugini]

Greetings All,

I have a multi-user mode issue that I am hoping someone can provide some advise. This is the very first FileMaker system I ever built, and I may have made some bad assumptions.

I have a system that I am rolling out for our company. It consists of the following files:

Menu.fp5

Contacts.fp5

Jobs.fp5

Invoices.fp5

TimeCards.fp5

Staff.fp5

There are other files that are not relevant also.

(for shorter version, skip to THE PROBLEM)

I have implemented a custom authentication system so that I can provide very granular control on actions. Menu items, status area, and other items are all blocked with the built-in security model, and all actions are scripted and tied to buttons.

I developed the system in single-user mode (of course), with what I thought was full knowledge of how global variables work in multi-user mode (each user has his own copy of globals). This system is being rolled out to a heterogeneous network of both Macs and PC's.

THE PROBLEM:

--------------------------------

The way I implemented the user authentication is as follows, I have a layout in the Menu.fp5 file that accepts a userid/password, and a button to Login. This checks the Userid/Password against stored values in Staff.fp5.

If the userid/password match, I set a global userid filed in each of the other db files through a constant 1=1 relationship. Then each scripted action that needs to be protected in any file references a set of privileges in Staff.fp5 using a relationship that uses the gUserid on the left side.

The problem is users are closing DB files (for example Contacts.fp5) to get them out of the way instead of minimizing them, then the next time that file is opened via the main menu, the value for gUserid is assigned by FileMaker Server, and it is not always what it was before the file was closed. This leads to privilege violations (as you can imagine).

My first though was to prevent users from closing files, but as I have been reading, a plug-in is required, and that is not an option for me. I need to build a solution without requiring any plug-ins. My second thought was to re-sync the gUserId fields when a file is opened, but that would require a reference to a file that stays permanently loaded, and I can't guarantee that without blocking a file from being closed.

Does anyone have any thoughts on how to solve this problem (hopefully without much retrofitting)? I am so close to rolling this solution out.

Thank you.

[danjacoby]

Maybe you can have the gUserID stored in another hidden file, and script the other files to pull the value from this extra file?

Just a thought. Let me know if it works.

[fperugini]

How do you hide a file?

[danjacoby]

When you access a file that isn't open, it gets opened, but hidden, which means that you don't see the file -- under the "Windows" menu you'll see the list of opened files; the hidden ones are in parentheses.

The hidden part is actually irrelevant, although you might want to limit access to this file so that nobody can mess up your script.

[cjaeger]

If the userid/password match, I set a global userid filed in each of the other db files through a constant 1=1 relationship. Then each scripted action that needs to be protected in any file references a set of privileges in Staff.fp5 using a relationship that uses the gUserid on the left side.

The problem is users are closing DB files (for example Contacts.fp5) to get them out of the way instead of minimizing them, then the next time that file is opened via the main menu, the value for gUserid is assigned by FileMaker Server, and it is not always what it was before the file was closed. This leads to privilege violations (as you can imagine).

Do not set a global in every file, make this a calculation or open script based on your relation to Menu.fp5.

Closing script in menu.fp5 should close all files or quit app.

Opening script in every other file should check for Menu.fp5::passwordOK="true", else close the file.

If there are no records in your file, or all of them are ommitted, the relation is invalid. therefore, you should base the relation on a global on the left side which will always be filled with "1".

[fperugini]

Thanks Christian.

I'll think about the ideas in your post.

[Kundinger]

Hello Frank,

Your issues are not uncommon to 'custom' log-in systems. The key to this type of system is to 'think out' every possible user-scenario... meaning users tend to do the unexpected.

To solve the issue of 'improperly' closed files (force-quit, crash, close, quit, etc.), I have implemented 'opening' & 'closing' scripts to reset globals.

I also utilize a set of script steps in the 'closing' script that will check to see if the user is actually 'quiting' the system or if the user is trying to 'close' a specific file. If the user is 'legitimately' quiting the system (from the Menu.fp5 file)... the Menu.fp5 file will close each file properly. If the user is 'improperly' closing files... the 'closing' script will 'alert' the user that they are attempting to perform an 'improper' operation. The user will then be given a few 'choices'... "Cancel"... to continue working; "Hide"... to hide the system; or, "Quit"... to quit the system.

It sounds like you have developed a decent system with much thought into how users will interface with it. The above ideas should be able to be integrated with minimal effort and minimal user 'confusion'.

I hope these ideas help. Feel free to contact me directly for further assistance. Good Luck!

Bob Kundinger

[email protected]

[Anatoli]

I've found that closing scripts are NOT executed if networked file is closed by Ctrl+W. FM5.5, W2k.

[Lee Smith]

Hi Anatoli,

How convenient, you can just copy and paste the same answer on two different post.

Lee

[Anatoli]

Oh blast!

I was discovered!