ISO FileMaker Magazine

As technology advances and becomes as critical to our digital lives as water is to our physical well-being, we must be keenly aware of whether that "water" is tainted with harmful elements that could harm us.

This sentiment applies not only to your health but also to your technological security concerns. For most technical systems, we may be inclined to assume that "big tech" — meaning the creators of the software or technology — will automatically make things safe for us. However, there may be risks that neither the provider nor the user recognizes until they surface.

Recently, the FileMaker landscape has been impacted by several critical security findings, making it essential for you to understand your level of exposure.

In many cases, threats may be mitigated by measures within your control. However, in some instances, upgrading is the only viable solution. Many FileMaker systems still rely on versions much older than FileMaker 19, following the old adage, "If it isn’t broken, don’t fix it." This time, however, it is very, very broken. Older versions of FileMaker Server, if publicly accessible, can be hacked in ways that conceal any traces of intrusion. In this case, using outdated versions is a risk you can't afford unless you're prepared to accept that your system is essentially open to anyone willing to find it.

If there's one thing you shouldn't ignore from the start of any FileMaker solution, it's the way security is going to factor into your creation. You need to know who the users and groups are and what their access rights are. These access rights are called privilege sets within FileMaker.

All too often, security may be an afterthought because most of the fun typically lies in creating solutions to the problems. The real trick is to create the solution to the problem while simultaneously considering how security wraps around that problem.

Unfortunately, with FileMaker being such a flexible platform, testing those access rights is not obviously easy. We have one simple way of testing one privilege set versus another: logging out of the system and then logging back in as another user. This process, while critical, can seem like a hassle, so it's often deferred. With the information in the associated video and technique file, you'll enjoy learning about a very easy-to-use system that allows for testing things quite easily. The solution simply takes advantage of part of how FileMaker works after the authentication process. Need to up your security game within FileMaker? You're sure to find some answers within this solution.

As with most every database solution, one of your primary goals is to facilitate easy navigation. You want users to be able to get to where they wish to go without hassle. You also want relevant navigation based on the fact that a database isn't just a one-trick pony. A lot of software tends to focus on one singular thing. However, in many database systems you may be catering to wider range of users.

This is where it becomes helpful to have a navigational method which is not only flexible, but easy to maintain. Using a portal to accomplish this is an obvious solution. But what about making the portal vary the navigational options based on the logged in user?

This can be done when you marry FileMaker's native security controls with the values shown within a portal. In this video, we walk through a "build it with me" approach to implementing this exact feature. Setting up a navigational sidebar menu system which responds to the user who's logged in. This system can either be a bit more general or as granular as desired.

If it's not absolutely necessary, preventing a user from accessing parts of your software is a bit better than letting them know what's possible or what's hidden from them. It also allows a given group of users to focus better without presenting options which may not apply to the functions they perform.

In this video and technique file, we take a look at two tricks combined into one. We're making single segments of a button bar hide and show, without resizing, and we're doing this based on a user's collective security access.

If you've had a FileMaker solution grow to the point where all users still have access to all things, then you'll find some great information in this video about limiting access to certain features of your user interface. This video and technique file will give you the insight into providing a limited set of options based on the access levels you define.

Every once in a while you need to store something with an extra bit of security. Maybe it's a password or some super secret text with a winning stock market strategy. Whatever it is, you don't just want to rely on the authentication, privilege set and possible EAR (encryption at rest) on the file.

You want to store the data itself with even that much more security. By encrypting it with CryptEncryptBase64() of course! The trick is this. How do you capture that data, before it's written to the database file and then store it securely.

And, beyond that, how do you provide the user with an easy way to get the information back out? Well, in this video and technique file I present a single script which handles both directions of the encryption and decryption which is very easy to associate to any given field. The user has convenient feedback that the data is secured and can get what they need when they need it.

Need that extra bit of data protection while still providing the user with an easy-to-use interface? This video will provide you with the details and know-how.

Even if it's not a super interesting topic, and really only applies if you're managing a FileMaker server, it always pays to know how things work behind the scenes. If you've never used FileMaker's external authentication via LDAP then you'll want to watch this particular video.

If you're creating any type of FileMaker solution which needs to know when your users both enter and exit the system, which especially applies to using external authentication, then you'll enjoy the super simple access log discussed within the video.

There's even a great tip about adding a unique backdoor for emergency access to your files - should you forget your master password for Full Access. Remember, this may seem like a boring topic but it's critical information to have if you're going to be managing any type of complex solution with centralized access controls.

Pretty much all over the world you'll find technology which can scan barcodes. Smartphones with cameras just waiting to scan either their very first, or even their 1000th barcode scan. With just over a decade since the first iPhone came out, it's pretty hard to not find a use case where a barcode can help you retire some antiquated manual process. Barcodes can be used almost anywhere to make faster and/or easier solutions.

Given that FileMaker Go supports all major barcode types, you simply need a method for creating your own barcodes within FileMaker. In 2017 I created an article about using a free JavaScript library called QRious and in this article I bring you an updated implementation plus a new library with the inclusion of how you can secure your own barcode content.

If you're ever in the need of making sure that the barcode you're scanning has originated from your FileMaker solution then you'll find the know-how you need within this video and the associated file. The additional JavaScript library I've discovered is also a great enhancement if you need vector based barcodes with support for unicode characters which are not supported by QRious. Need anything to do with QR barcodes? Check this video out!

Security. While it isn't as sexy as a nice UI widget or as crafty as a really cool scripted workflow, setting up your security is something you must consider before any database deployment. When it comes to security, you can't miss a beat. If you do, then that one attack vector might be the one that bites you. And, unless your FileMaker solution is never going to connect with the network at large, knowing who can do what within your system is an essential requirement of security.

Getting to know FileMaker's privilege sets, and how they work, is one thing. But, weaving this knowledge into a system which provides a good degree of flexibility is another. If you're interested in the User/Group/World permissions model, then applying it to your FileMaker solution isn't too hard. You just need know which fields to add and how to make them interact with the rest of the security model in order to accomplish your intended goal.

This video, and the companion file that comes with it, will provide you with the best starting point possible for figuring out how you might want to integrate your security objectives. If you've never quite gotten FileMaker's security under your belt, then give this video and file a good look over.

Keeping things private, so only those who need access can access them, has been a desirable situation for as long as people have wanted to keep things private.

The only difference between the invention of invisible ink and today is trying to keep ahead of those who have the knowledge on how to access what you're trying to keep private. It's the eternal game of cat and mouse between those who seek to access what they shouldn't and those who want to keep those people out.

Within FileMaker, we now have the option of using the FileMaker 16 added Crypt* functions. This functionality, formerly only accessible through plug-ins, can now be used to securely encrypt your data within regular text fields. There's some terminology and understanding that needs to be paired with using the provided functions in order to make sure you're staying truly as secure as you possibly can when using them.

This video provides the information needed to understand what that terminology is and how to securely encrypt private data within you own FileMaker solutions.

When developing a FileMaker solution, you often want a system where the distribution of labor is such that other administrators can create and manage the users of that system. It can't always come back to the developer who has the only Full Access account.

When considering FileMaker's authentication methods, you basically have three options. Internal, external and third party. The external option is typically Active Directory on Windows or OpenDirectory on Macintosh. The newer third party options are from Amazon, Google and Microsoft.

However, with both external and third party, you have to manage users and their passwords outside of the FileMaker space. If you're wanting to use FileMaker itself to mange users and passwords, then you'll be using FileMaker's internal accounts. The trick is to have a way to manage those accounts within your database. And, that's up to you to both create and manage.

This video is about using a dedicated Users table and how you can securely manage the communication between your table of users and the actual users list within FileMaker's internal accounts. Need to provide a secure method of allowing certain users the ability to create and delete accounts? This video will have the know-how you need.