Custom Security - Assistance Needed

[JTC]

I am in the proccess of developing a rather large system for a client of mine. My client has recently requested some advanced security features that will require the implementation of a custom security system. I am well versed in most FileMaker related areas, but custom security systems are new to me. Yes, I know I am in for a TON of rewrite. I get paid by the hour so, that's not an issue . I have learned from experience that my first approach at solving a FMP problem, is not always the BEST way to do it. Becuase of the system size, and the amount of rewrite involved, I want to make sure that I do not overlook anything.

Basically, this is what I have in mind. I have a users database where Username, Password, and security access level are stored. Someone suggested in another post to separate users and passwords. Could someone explain the logic behind separating Users and Passwords? Does anyone have any tips for a custom security system first timer? Beter yet, does anyone know of an article, or demo that is available online? Thanks in advance!

Regards,

John

[Pupiweb]

Take a look at The Gateway, an Open Source login solution at www.fmfiles.com

[djgogi]

The first question to ask, yourself is who will enter in contact with the solution and what level of experience would they have in using(understanding) FM .

The Pupita's Gateway solutions is appropriate if the answer on previous questions is:

only my client staff and low.

Otherwise, I'll suggest you to build the protection system based on FM built-in scheme, since anybody with a minimum of understanding of FM functionality would take 30 secs to create you an new user with whatever priviliges he'd liked.

Dj

[StevenB]

I developed a custom security solution that controlled approximately 100 areas of the program.

I created two passwords for each file in the solution - 1 password would grant full access and the other locked up most of the file. I set the one that locked up the file as the auto logon password.

I created a user file that keeps Name, logon ID, password, department, email address and access rights.

Access is broken down on a screen where you can click on what the user can access and what parts of the program they can't access. When you check an item - say Print Job Tickets. It changes that field value from a 0 (Zero), the default value for the field, to a 1 (one). When you are done, you click the Grant Access button and it takes all the fields that control access and makes a 100 character long "word". The access field is a text field so you can read for the 0 or 1.

When a user successfully logs in the access field gets copied to a global field. Then when the user tries to access part of the program, I use the Middle command in a script to read the global and see if they have access:

Middle (Defaults::gAccess,25,1) = "1"

If you need more info - email me.

Hope this helps.

[Kundinger]

Hi John,

I have created similar systems to "StevenB".

I use a "Main" file on each workstation with relations to server files on a FMP server. I also created two passwords for each file in the solution (FMP built-in security) - The first password grants full access to me as the developer. The other password locks up most of the file for my client users. I set the one that locked up the file as the auto logon password.

The user 'launches' the "Main" file and is taken directly to a "Log-On" layout. After entering a user name and password, a script 'authenticates' them in a 'hidden' "Users" 'prefs' file. The "Users" file has all the users, passwords and user & group privileges for each user. The 'privileges' for each user is 'set' into the "Main" file while a user is 'Logged-On'.

The "Users" pref file has a listing of all related files and the capabilities each user has. A client 'manager' can access this file from the "Main" file through relations and setup users, passwords, priv. ETC. This person clicks specific checkboxes next to each filename to give users and groups certain capabilities. Behind the scenes, a privilege 'code' is generated for each user.

EX. 104AGC142HAB643...

The first 3 chars. are the user number. This is used in files where only that user has access to a specific record. the other chars. correspond to certain related files and what capabilities users have in those files/layouts/records. You can create an endless 'mix' of capabilities. Think of the combinations of: 'NoAccess', 'Delete', 'Print', 'ViewOnly', 'Edit', 'Search', ETC. ETC. ETC.

The "Main" file has all the 'interface' components with buttons, scripts, portals, ETC. to the related files. The users don't access the related files directly. They will click buttons in the "Main" file to take them to other "Main" file layouts with related data. When they click a button, the scripts in the "Main" file and related files 'talk' to each other to verify the user privileges. I also use the "Middle" function to 'get' the user priv for the task & data they are trying to get to. By doing this, certain users can 'view', edit, print, search, ETC. certain records. Other users may be locked-out completely. In essence, I have file/layout/record security with differing levels of capabilities.

For added security, I have the "Main" file do some 'resetting' when users start or quit. The users don't access any related files directly. If they do bring a related file to the 'front' or try to open a related file, they encounter a "Warning" message which 'hides' that file, and takes them to the "Main" file. In the "Users" pref file, if someone should 'duplicate' a user, the new or duplicated user has all priv. set to "NoAccess".

I have way too many thoughts on this... I have spent better that five years refining this... I started this type of system back in FMP 2 with 'lookups'. Much easier now with relations. Not the best, but doable.

Hope this helps...

Bob Kundinger