So I've worked on a few solutions that contain multiple files and CWP or WebDirect and have noticed that there is a general tendency among developers to use a shared login approach to related files. That is, storing a 'system' user in multiple FileMaker files whose purpose is to explicitly grant access to users logging into an entire FileMaker solution without requiring an actual, internal FileMaker account for that user.
Here's my current use-case: I have a multi-file solution that contains a single user account that is being used by the Custom Web Publishing Engine to grant access to all related files once a user has authenticated into the CWP solution. This works great from a simplicity standpoint as I do not have to worry about adding, removing or verifying accounts or passwords beyond the CWP Database, but because that single user account is being used by multiple accounts it violates our security protocols by preventing an audit from telling which user has performed which action, as the modification user on a record would just say 'cwp_user' instead of the actual Account Name that was used to modify the record. This is obviously problematic in an environment where data integrity and audit trails are used.
My solution to this problem was to script the addition, deletion, and overall control of all internal FileMaker accounts being added to my entire solution. However, in going about this I made one glaring oversight when designing the system; there is absolutely no way to perform migrations between different versions of the same FileMaker file using the built-in FileMaker Account controls. Steven Blackwell has always said often and loudly, "DO NOT ROLL YOUR ERSATZ AUTHENTICATION SYSTEM, USE THE BUILT-IN FILEMAKER SECURITY CONTROLS" but in my case I really have no choice but to store a users' password outside of the built in FileMaker Account controls as this is the only way that I can sync FileMaker accounts between a development and production environment!
Am I wrong? I've been wracking my brain for a few hours trying to think about various ways to go about this, but right now this seems to be a pretty major oversight in the way that FileMaker Account Security is currently handled because it makes developing on Production and Development environments almost impossible without rolling your own ersatz authentication system that stores user passwords in a database table.