ISO FileMaker Magazine

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.

These are often asked questions regarding setting up a new FileMaker database system. "How can I limit when the user can enter data into the field?" Or, the alternative, "Once the user enters data, how can I make sure they don't change it unless I want them to?"

Both of these types of questions can be answered using a variety of methods. The core to understanding their answers is that there's really only only two methods for limiting field access. One is controlling the display of the field and the other is truly limiting access to the field data itself.

Using the knowledge in this video you should be able to come up with a method which fits your exact situation. The video walks through the use of the various options which FileMaker provides for limiting access to a field. If you'd like to know which options you should use to control access, then give this video a view.

¿Has pensado alguna vez qué pasaría si perdieras justo ahora tu solución FileMaker? ¿Podrías recuperar fácilmente los datos? ¿Y la estructura de tablas y su correspondiente programación?
Las copias de seguridad es una parte muy importante que hay que considerar en todo proyecto de FileMaker. Por eso, conviene tener un plan de emergencia para evitar la pérdida de datos.
En este vídeo aprenderás a hacer copias de seguridad de tus archivos FileMaker, tanto si los estás usando en local como a través de FileMaker Server 17.