For reference, here was the object definition we were using in our sample Transfer configuration.

The process is very simple. Recall that we prefixed our Transfer properties with "Enc" to know which fields are encrypted. Let's create a getDecryptedMemento() method. It will loop through all of the keys in the memento, which is just a struct, and decrypt any of the encrypted fields, saving them as new keys in the struct (i.e. "EncHome" is decrypted as "Home" in the struct).

Something like this will do the trick:

Not much to it. Note that we would use the same decryption function as we are using in onMissingMethod for the dynamic accessors. I'm calling it decryptValue() for this sample.

In the end, our getDecryptedMemento() method returns a memento that looks just like the Transfer-generated getMemento() output, with decrypted versions of the encrypted fields!

First, let's consider the object definition in our sample Transfer configuration file.

Note that I have prefixed the Transfer properties with "Enc". This isn't required, but will simplify our processing later on. So in this sample, we have 4 properties: Home, Work, Mobile, and SMS. The concept is that these are client phone numbers that we want to protect with encryption. So, Transfer will generate getEncHome(), getEncWork(), getEncMobile(), getEncSMS(), and corresponding setters. However, we want to provide getHome(), getWork(), getMobile(), getSMS(), and corresponding setters, that get and set the properties after encryption/decryption.

Use onMissingMethod()

To accomplish this, we might have an onMissingMethod() function in the decorator like this:

As a good security measure, we use an "encList" string to check that only proper methods can be called. Then we examine the method name. If it starts with "get" or "set" and ends with one of the list items, we proceed. Thus, we'll process a method like getHome(), but not a method like getFoo(). We then call getEncHome() and decrypt it for getters, encrypt and call setEncHome() for setters.

Dynamic Method Calling

But alas, how do we do this dynamically without a long if-then-else chain? We call the proper method by referencing it from the component's variables scope. Terrence Ryan describes this in his blog post Cheap and Easy Dynamic Method Calling in CFScript. We construct the method name, in our case, by inserting "Enc" after the "get" or "set" prefix of the method name passed into onMissingMethod (thus "getHome" becomes the Transfer method "getEncHome"). Assign the function to the local "func" variable, then call it as if "func" was the function. Finally, handle any encryption or decryption that you will be doing. For this sample, I have encryptValue() and decryptValue() methods handling the details of that work.

Summary

We've used two solutions to handle multiple encrypted fields in the decorator. First, we used onMissingMethod() to handle processing of all of the properties in a single method. Then, we used dynamic method calling to call the Transfer-generated accessors within onMissingMethod().

The end result is being able to use setHome(), getHome(), etc. with the encryption and decryption being handled automatically. Great!

In addition to accessors, we may sometimes want to use the object's memento with the Transfer method getMemento(). In my next blog post, I'll demonstrate how that process can also be done very efficiently.

My web service is a facade CFC powered by objects being generated by Transfer and ColdSpring. So I conveniently have access to the objects' getMemento() or getPropertyMemento() methods.

I had a method in the web service that would accept several arguments and perform the simple task of processing them and saving them to the database. It returned a single boolean indicating success or failure.

The web service is just used by another web server that doesn't have access to the database and can't run Transfer (because it is currently running CFMX 6). This web server hosts a page with a form; when the user submits the form, the action page invokes the web service to process and save the information.

I needed the action page to display some data that wasn't available in the form data that was transmitted. For instance, a pull-down menu allowed the user to select from a list of sessions, but all that is transmitted is the database ID of the session they chose. My action page can't display any details about that session unless it makes another web service call to retrieve the details of that session. And I have to write the code for that web service method, which up to this point was unnecessary.

Aha! I changed the web service to return a struct that still contained the success/failure boolean, but also contained mementos of the objects that were created or referenced when processing the request. Now my web server invoking the web service has all the details of the session at its disposal for display on the action page.

What's the big deal, right? Who cares about one more web service call? Well, I'd like to keep the chatter between the two machines down to a minimally required amount, and besides, thanks to getMemento(), adding all of that data to the web service's response took one line of code, and way less time than it would take to write that extra web service method to retrieve session data, and also way less time than it took to even write this blog post.

Here's the general thought process of the code in the web service (abbreviated to just show the point of mementos):