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:


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.


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:


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.


  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

About The Author

25 thoughts on “Extending WebDirect: URL Parameters”

  1. Mike – first I want to thank you for this solution. It solved an issue I have been grappling with.

    The solution works for me in Safari, but it does not give me the find results in Chrome or Firefox. Any idea why?

    Thanks again – Sam

  2. Hi Mike – hoping you might have an answer to this:

    I paused the script and this is what I got in the Params_g field

    Warning: fopen(/tmp/EDA79FD8-EFA7-B649-9949-784238DC481C.txt) [function.fopen]: failed to open stream: No such file or directory in /home/smilep6/public_html/php/fm_read.php on line 10
    Unable to open file!

    Script works in Safari, but I get the above in Chrome and Firefox.

    Thanks in advance – Sam

  3. Hi Sam,

    It seems that the second step listed above is not being triggered, so you may want to look there. This is the part in the startup script that calls the fm_write php script. That is where the UUID is passed to php in order to save the parameters in the session. There should be a pause in the script to allow that to happen. This was tested in Safari, but should work in other supported browsers.


  4. Thanks Mike,

    As I said it works fine in Safari, but not in Chrome or Firefox.
    Could you do me a favor and test it on your side with Chrome and/or Firefox to see if you get the same issue.

    Thanks in advance – Sam

  5. Hi Mike

    The strangest thing started happening as I tried to figure out why the WebDirect Params was not working in Chrome and Firefox.

    Now when I try it, the find gets hijacked and in the Params_g field this gets placed “* Domain Sponsor Redirect

    ” and the browser gets redirected to: http://www.searchingresult.com/?pid=9POLWR59T&dn=smilepix.i.com.com&rpid=9POKA9272

    This is now happening in Safari, Chrome and Firefox.

    I am doing a virus scan right now on my Mac, but I don’t have a clue as to why this is happening.


  6. Sam, it sounds like this is depending on where your PHP files are hosted, and how they are referenced in the FM file. Is the domain you are using out of date? You might try to point to the location of the php files with an IP address instead. 

    By the way, I tested in Chrome and Firefox and both of those worked for me. Firefox is not a supported browser for WebDirect, but this worked.


  7. Hi Mike,

    I found my issue. I was calling the script from http and getting errors. Once I moved the scripts to https everything worked fine in all browsers.

    It seems like you are on a Mac like me so maybe you have an answer to this:
    When I call the script in Chrome or Firefox the script goes right to the database and presents the find.
    When I call the script in Safari, the script goes to Filemaker Webdirect login page and requires the Account Name and Password and then I have to select the database from “Select a database” before the script continues. Is there a way for the script to run in Safari without the user having to login? I tried enabling Guest account in Security like Filemaker recommended, but that did not work.

    As always, thanks for your help – Sam

  8. Sam,

    I believe this may be done in the file options, and set it to auto open with specified credentials. Otherwise, logging in is usually a good thing.


  9. Hello Mike.

    First of all thank you for providing this solution.
    I have succesfully implemented it.
    In my application it should be possible for the users to either access it in the normal way (using the normal webdirect URL) or using the php method.

    I need a way to identify if the user is accessing the tool using php or not, so it will only run the Load Web Parameters script when necessary. For some reason, right now, when entering the tool in using the webdirect URL, it makes the webdirect engine crash on the Load Web Parameters script.
    How would you recommend to handle this problem?

  10. Dylan,

    Make sure you are running the latest update for FM Server. I haven't seen it crash when logging in normally. You can't detect if you are arriving at the URL through a redirect like PHP is doing or not without testing for the parameters you pass in. You could test for any data as a result of the insert from URL script step, but it still needs to test for passed parameters.


  11. Hello Mike,

    Im on Window 2008 R2 SP1 running Filemaker Server 13v5. Im using http not https. Im getting a error of 1631 on Insert URL script step. If I use the same url in this step and set it to a web viewer, the web viewer will display the result. Any ideas.

  12. Can we use the same consepts to redirect users at the end of a web direct session to a specific HTML page? EQ a different page for each DB hosted.

  13. Jesse, indeed the update to webdirect in FM 14 obsoletes this technique. I would not recommend passing credential in any kind of link or URL. If you do not need users to log in for security purposes, then you could use the guest account and pass another parameter to store in a field. 

  14. I’m finding that I can only display a web page in a webvieweer in webDirect if the web page is https. It seems to be security related. My webDirect file is httpsWeb is https.

    Does anyone know a way to display an http site in webDirect?

    Thanks, Mike

    1. Hi Are,

      Using the built in send email functionality, sending email from WebDirect effectively happens from the server, so are subject to the same limitations as server side scripts. You can write files from container fields out to the document folder in the filemaker server folder and attach it to an outbound email from there. Does that help?


  15. I call this URL, and while the WebDirect file opens, asks for credentials, but then, no search is executed, using the demo file:


    The desired record exists, but I get the full found set.
    I did not alter the demo file, not the PHP files, but to change the file name and also do that in the PHP file: “fm_link.php”

    What might I be doing wrong?

  16. I am capturing the params, and see this at the bottom of the field:

    500 – Internal server error.

    There is a problem with the resource you are looking for, and it cannot be displayed.

Leave a Comment

Your email address will not be published. Required fields are marked *