Extending WebDirect: URL Parameters

FileMaker WebDirect represents the next step in FileMaker’s WYSIWIG web publishing strategy. It was introduced as part of the FileMaker 13 platform and runs as a feature of FileMaker Server.

As of the FileMaker Server 13.0v2 update, the ability to pass in parameters via a URL has been removed due to unspecified security concerns. Despite this omission, it seems a reasonable expectation to be able to pass parameters to a web app in order to do something. Some have referred to this functionality as “Deep Linking.”

In the example presented here, we demonstrate how to bring this ability back to WebDirect. It involves a few PHP files to make it work, along with a startup script in your FileMaker file to check for the existence of any parameters. There are no Plug-ins required, or the need for Custom Web Publishing…only WebDirect and some PHP.

The WebDirect Recipe

To be able to pass in parameters to a WebDirect session, we will utilize just a few external PHP. There are several ways to go about this, and differing approaches may suit your particular use case. For this example, we will highlight a more general approach that provides a great amount of flexibility. This script will also allow us to pass in as many parameters as you need to.

Here’s how it works, in only three steps:

1. The initial page, “fm_link.php” will set all the passed parameters into a session variable.
2. Next, a web viewer will set the session variable to a temp file on the server using the next PHP page, “fm_write.php” using a key assigned by FM, and destroy the session in PHP.
3. Finally, an Insert from URL will access the temp file and convert the returned parameters as local variables in FM, then perform a find with some of the parameters that were passed.

With three fairly simple PHP scripts, we will store all parameters in the URL string as key-value pairs. An example of this might be:

http://my_server.com/fm_link.php?key=value&key2=value2

A More Detailed Explanation

In the above example, we get an array with two parameters in it, key and key2. The first PHP script will store these in a session variable, and then redirect to our WebDirect file. The way session variables work in PHP is that a cookie with an ID is assigned when you open a session. From that point on, you can assign as many variables as you would like to the open session and those are stored server side, so the browser only knows the session key.

At this point, the regular FileMaker security settings can be invoked, according to how you have configured them. If you require a username and password, they will be required before proceeding.

Once you are in a WebDirect session, there is a script trigger set on the file that runs “onFirstWindowOpen” that will act as a startup script. In this case, the script takes us to a layout that will act as a splash screen and has a couple objects that we will use to retrieve the parameters stored in our PHP session.

The first object is a web viewer that loads our second PHP script, and since our browser already has the cookie with our session ID, the server side script has all the parameters we stored from the first PHP script.

Here is where things get interesting, since you might think we could just scrape the HTML returned to get all the content we serve it, but WebDirect web viewers are ONLY able to get return the URL of a web viewer. Instead, we will also pass in a key generated from FileMaker to our web viewer, utilizing the Get ( UUID ) function. I will explain why in a moment. The other object that needs to be on this layout is a global field that will be the target of a Insert from URL script step.

Now, a funny thing about Insert from URL step, is that this happens on the server in a WebDirect session. Remember that with WebDirect, FileMaker Server is doing a lot of the work that would normally be done by your FileMaker Pro client. If you were to look at what IP address the request is made from during an Insert from URL script step, you would see that it is the server’s IP address and not where your web browser is running.

This also has other implications, since no cookies are stored at all by the server, and there is no access to the PHP session we created with our initial PHP script. However the web viewer inside the WebDirect session does use the same PHP session. So now that we have given the second PHP script a UUID, that script will write a temporary file on the server that contains all our parameters.

Meanwhile, in our FileMaker script…

Since we know the UUID, we generated it and have it as a script variable, we can reference that same UUID in the Insert from URL script step that calls our third and final PHP script. This final PHP script reads the contents of our temp file on the server, then cleans up by removing it.

Now all the parameters are in a global field in FileMaker where we can parse them and act on the contents to our hearts content. From here, it is really up to you as to what you do with the parameters, depending on your project’s needs.

Note: The PHP script named “fm_link.php” has a few optional default parameters that you can hard code if you like. These are for the default location of your FileMaker Server and the file name of the hosted file you would like to link to.

fmurl=my_filemaker_server_address
fmfile=my_filemaker_file

If these are not set, you will need to pass them in via URL parameters. A complete address with these parameters included might looks something like this:

http://my_server.com/fm_pass.php?
fmurl=my_filemaker_server_address&
fmfile=my_filemaker_file&
key=value

Best Practices and Security Concerns

As far as security goes, this technique should at the very least be as safe as using PHP sessions in the first place, which are very common. We also do a bit to sanitize the content of the UUID string that gets passed in to prevent malformed naming of the temp file on the server. Again, this is as safe as using sessions in the first place, since PHP sessions are stored as temp files on the server.

This also means we should not need to worry about folder permissions on the server, since PHP should already be able to write files there. We also do not need to worry about garbage collection since the file is removed immediately after being referenced from WebDirect, all of which is transparent to the end user and happens quickly. Even if it did not delete the file, the temp file typically gets routinely emptied on the server anyway.

Of course, best practices should be followed for passing in parameters in the first place. You would not want to be passing in any kind of sensitive information such as usernames and passwords. Keep in mind that these would all show in a server log anyway, regardless of the application you were passing it to. Instead, you should reference the data that is securely stored in your database

I should also point out that this solution does not require that the PHP files be hosted on the same server as the WebDirect or your FileMaker server. It can run from another PHP enabled server, and also does not require CWP (custom web publishing.)

To run the sample files provided, host the FileMaker file on your WebDirect enabled server, and install the PHP scripts on your web server. You will then update the startup script with the location of the PHP scripts, and optionally, update the PHP “fm_link.php” file with the location of your FileMaker server.

Demo Files

Get the files from GitHub:

Note: Click the “Download Zip” link at the bottom of the right hand column on the GitHub page.

Special Thanks

Many thanks for Mike Beargie and Steve Senft-Herrera who both shared feedback and their own approaches to the same problem, and took the time to review my initial approach. Mike presented his own solution at Pause on Error.

References

1. FileMaker WebDirect: http://www.filemaker.com/products/filemaker-server/webdirect.html
2. Introduction to FileMaker WebDirect: http://help.filemaker.com/app/answers/detail/a_id/12794/~/introduction-to-filemaker-webdirect