Leaderboard

Thank you, Josh, for reconstructing this important thread and for posting it. What did we learn from this episode? Here is a summary: · What we call something matters. Calling a process 2 Factor Authentication does not make it so. · Manipulating the business logic layer, i.e. scripts, of the FileMaker Platform in an attempt to create additional security features requires an in-depth and nuanced understanding of how that layer performs, particularly in relation to external API’s or under the influence of such API’s. · More likely than not, an ersatz process will introduce additional vulnerabilities into a system, while at the same time retaining all the vulnerabilities the underlying elements that comprise the process have in and of themselves. · The business logic and data layers of a FileMaker Pro file are subject to manipulation by attackers in ways that result in the defeat of the ersatz process. The Platform has tools and features that diminish these risks; however, developers frequently do not employ these tools. · To paraphrase the late Will Rogers, “It’s not what you don’t know that hurts you. It’s what you know that isn’t so.” Steven H. Blackwell

Asked and answered on community.claris.com Don't do it. Stay within support parameters. The philosophy of CentOS is to favor stability and reliability and to NOT automatically jump to the latest of everything. 7.8 is still under Long Term Support until 2024 and is the most proven 'current' CentOS.

This forum has members from all around the world.

My 15mins of fame! Let me help you sync accounting data to QBO from FileMaker.

This is no accurate. How they handle the processing is VERY different. Tools other than FMPerception: Run DDR Import DDR ( ours takes 10-12 hours, processing and analysis happens here ) Search for some stuff. Make changes. Export DDR Import DDR ( 10-12 hours, processing and analysis happens here ) Search for some stuff. Roughly getting updated info every other day. FMPerception: Run DDR Open FMPerception ( < 7 secs ) Search for some stuff ( the processing and analysis happens now ). Make changes to database files. Export DDR Open FMPerception ( < 7 seconds ) Search for some stuff. Getting updated info on demand as needed. ( Maybe an expanded definition of "realtime", if you want to call it that. But my developer intelligence continues working in realtime with no interruption ). "Realtime Developer Intelligence" is the marketing phrase they decided to use. In the end, what it is called doesn't matter. It is, as close to in process updates as we are going to get until FM makes other changes. If you aren't comfortable calling it "realtime" then don't. Most people really don't care.

THANKS, very nice, was about to make my own, but this is awesome

f.lux FTW!

I think another likely scenario, in addition to a "test" file, is when a user who has sufficient access, or an administrator who doesn't realize the risk, puts up a file that is not part of a secure solution... in which they don't consider the data to be critical. Honestly, I have put many such files on servers in the past... Thanks for identifying this issue, Steven.

I agree that any additional measures a developer takes are unlikely to increase the security of a file. I don't think any serious developer adds security features with this expectation. They are usually added because the FileMaker security model is not suited to all client requirements. Take the Role-Based-Access-Control model (RBAC), for example, which has grown in popularity in the last few years. It isn't possible to implement RBAC using the default FileMaker Pro security features because users can only be assigned a single privilege set, which torpedoes the inheritance concept that RBAC relies on. So, the only option if you want to implement RBAC is to create your own RBAC tables for users, auth items and child auth items and use them to manage access. And you use them in tandem with FileMaker accounts that are as restrictive as possible while still giving users the access levels they need. Does this make your solution insecure? Only if you mess up the implementation. But, as Steven points out, your solution is also insecure if you mess up the implementation of a regular FileMaker security set up. I do think getting the basics of FileMaker security right is essential and I appreciate the points in this blog. I also think that with most FileMaker solutions you are best served sticking to the built-in FileMaker security features, even if they do make development more time-consuming. But in some cases you do need to go outside the built-in security in order to provide users with functionality and compete with other products. At heart, FileMaker is a DBMS like any other and in other DBMS (Oracle, MSSQL, MySQL) managing security through customized tables on top of built-in security is common and perfectly acceptable.

Thanks for the post, Steven. Do you know if enabling Encryption At Rest will have any performance impacts?

>> They are incorrect; yet, they believe that they are correct, and they are unaware of their errors. That reminds me of that Mark Twain quote: It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.

Thanks Steven and Wim.... Very useful articles while working with FMS 12.

Yes you do. FMS will look in all the nodes set up in the Directory Utility for authentication. Sounds like you already have the know-how in house if the IT people bind the workstations to the AD. Otherwise a google on "10.6 bind active directory" will get you some tutorials.