Proposed new security system for ebase 2.20.fp7
Introduction
ebase in .fp5 handled most aspects of security using custom scripts; all regular users shared a common, invisible (auto-entered) FileMaker password, and logged in using a custom-scripted process. This approach was necessary because ebase's requirements exceeded the capacity of FileMaker native security features.
Some of ebase's requirements (notably the ability to store a number of user attributes, such as default log code and data editing privileges) still exceed FileMaker 8.5's native feature set. On the other hand, FileMaker's ability to provide richly configurable user privileges now exceeds ebase's old security features.
I suggest we consider the following suggestions, and revise ebase's security model (including login process) to let FileMaker handle what it now can, reserving custom scripting for only what FileMaker cannot handle.
1. Problem:
Password is case sensitive in .fp7 format, and admin password was not entered consistently across all ebase files.
Suggestion:
Establish [full access] privilege group and 1 uniform login/password in this group for all files:
Admin/admin
2. Privilege group must be established for day-to-day use. This group should have access to edit data & view layouts, but not to edit scripts or layouts.
Suggestion: create a second privilege group in all files (for now I'll call it "staff") with the necessary access settings.
3. Lots of files! Some contain data, and need careful access restriction. Others don not contain data, and could share a common password.
Suggestion:
a) Set all files that don't contain data to auto-enter a default staff-level password on launch.
b) For files that contain data (Contacts, Log, Location, Links, ContactLocations, CodeGenerator, ebase, Main, EmailArchive, EmailInBox, EnhancedData...), establish scripts to add, revise, and remove staff-level user accounts.
4. DBA needs to be able to add-remove user accounts without developer login.
Suggestion: Add scripts to ebase.fp7 that allow DBA to establish/edit/remove user accounts. These must call subscripts in each of the files mentioned in 2b above to establish/edit/remove accounts in all necessary files at once.
5. Original login process depends on dialog plug-in, with one FM password and custom handling of security & privileges.
Suggestion: transition to using FileMaker accounts & privilege groups for security (as described above), and only maintain ebase-specific settings in ebase.fp7 user account records. Revise log-in script to load ebase-specific settings to globals as necessary after user gets past FM login process.