How to Customize FileMaker WebDirect

There are many ways to customize WebDirect, a part of the FileMaker Platform that enables access to custom applications authored in FileMaker Pro via a compatible web browser. This is appealing for several reasons, including a zero-configuration client allowing for the commoditization of client computing requirements of your workforce.

While this is not meant to be an exhaustive list of the options to customize WebDirect, I would like to share just a few techniques that I have worked on recently.

Custom Login

A common request for developers is the ability to customize the FileMaker WebDirect login page appearance. There is, in fact, some support for this functionality where you can use completely custom HTML that submits using an HTTP POST request. It works fine; however, there are some limitations to this approach. Namely, if authentication fails, you may see the default WebDirect UI for re-entering authentication. Also, as a FileMaker developer, building custom HTML may be well outside your wheelhouse.

It would be nice if there were a way to keep this within the purview of FileMaker development, allowing you to use all the power and ease of custom application development that you know and love. The following demonstrates how to do just that.

By creating a security privilege set that is restricted to only WebDirect and carefully allowing only access to assets required for logging into a FileMaker application, we can craft an HTML form that will automatically submit as a POST using preset credentials. Essentially, these act as Public credentials. Normally you would not want to do this with a FileMaker Pro application, but since this is specific to web-accessible custom applications, the risks associated with being able to interrupt the sequence go away.

Learn more from the FileMaker WebDirect 18 Guide.

Generating the HTML Form

To make it easier to generate the HTML form, use the provided PHP script, which sets the needed parameters as an array of variables. The resulting HTML will build and automatically submit the form. This a page on which end-users will not view any content. Instead, the user will be sent directly, with authentication, to a WebDirect session. Note that this is not supported in FileMaker Cloud, as it does not support signing in with an HTTP POST request.

Once in a WebDirect session, you have complete control over the look and feel of the login form. This is where you can take advantage of the tools available in FileMaker, including error trapping.

Using Built-In Functionality

The referenced sample shown here demonstrates several techniques. Both are invoked by testing to see if we are in a WebDirect session and running an appropriate script. The first technique utilizes the built-in FileMaker functionality for logging in by invoking the “Re-Login” script step. The advantage is that you retain all the functionality that includes; resetting FileMaker account passwords on first login, OAuth authentication via Azure, Google and Amazon accounts, etc. You lose the ability to completely customize the built-in chrome that FileMaker provides to build the UI widget. However, you can completely customize the underlying layout and any additional scripting needed.

Using a Custom Authentication Dialog

A second option is to build your own authentication dialog using FileMaker fields and handle everything in a script. This puts the look and feel completely in your control as a FileMaker developer. You can also easily modify and update the form, all while only knowing FileMaker.

See the following video for a brief demo.

Get the Sample Files

Redirect on Logging Out

Developers also often seek ways to change where the user is directed to when logging out of a FileMaker WebDirect session. The default is to return the WebDirect Launch Center, which shows available WebDirect enabled FileMaker files. You can do this by specifying a query parameter named “homeurl” in the query string of a url when accessing a WebDirect custom application.

Read more about using a custom homepage.

This usage is part of the fmp url, which is also partially documented here in addition to the above link.

Retaining the homeurl Parameter

You may want an easier or shorter url for users accessing your solution. The easiest way to retain the homeurl parameter is to redirect users IN to a session with the parameter already specified. A user can log out in a couple of ways with WebDirect, including having their session time out on the server. This will end their session and send them to any referenced homeurl parameter.

Dynamically Setting the homeurl

You can dynamically set the homeurl with a few PHP scripts. Since you install PHP with FileMaker Server, you only need to enable it to use these scripts. You are not required to use PHP on the same machine on which FileMaker Server is installed. It is just easier to enable since it is there. Note that a separate web server with working SSL would be required with FileMaker Cloud, as no custom web publishing is included with FileMaker Cloud.

Jonn Howell demonstrated this in his 2019 DevCon session. View his presentation.

Download the files used in Jonn Howell’s presentation.

Included Landing Page

The files include a landing page, called “in.php” which sets a session variable in PHP. In PHP, you can recall a session variable in subsequent PHP pages by storing the values on the server and referencing a session ID by a cookie in the user’s web browser.

We set the homeurl parameter to another PHP script, called “out.php.” Here, we check to see if we have a session variable stored that we want to redirect to and use PHP to redirect to it.

Setting a Default Location for the homeurl

If we want to set a default location for the homeurl, we can set it in Filemaker by using a Web Viewer object to reference another PHP script, which we call “session.php.” This page simply writes the same session variable in PHP. The PHP involved is quite minimal.

When exiting the FileMaker WebDirect session, we move to the “out.php” page, destroy the existing session variable in PHP, and finally redirect the user’s web browser as needed.

Ending a FileMaker WebDirect Session

Finally, if you do not want to set a PHP session variable and then end your WebDirect session, you can functionally do the same by using javascript in a Web Viewer to redirect immediately.

This will also effectively end their WebDirect session. We have made a PHP helper script to make this easier. You can set the Web Viewer similarly as with the above scripts and specify the location as a query parameter. Something like the following:


You, therefore, can set the homeurl dynamically, so whenever their session ends, you can redirect them as needed. Or you can redirect them immediately if needed. You can pick and choose as needed.


These are just a few ideas for customizing and extending a FileMaker WebDirect deployment. With expected changes in direction from the Claris product roadmap, these types of options will be of growing importance. Showing what developers can do with these tools is empowering and should lead to new opportunities and growth potential at a significant value in the total cost of ownership.


20 thoughts on “How to Customize FileMaker WebDirect”

  1. Thanks Mike,
    Do you mention where to place this php file and what the url is that the client would call?
    You also refer to a ‘mylogout.php’ and ‘redirect.php’. Is there any more details or examples of these?

  2. Mike
    I have uploaded the file onto the FileMaker server, PHP is on, but each time I try to go to the URL it downloads the PHP file rather than runs it. Am I doing something really basic wrong???

    John r

    1. It sounds like PHP is not really enabled. What version of server are you running and how did you enable it? You can always create a test php file with just phpinfo() and see what it returns.

    1. I am not sure what you are trying to do, since this does not use iframes. Is the site you are redirecting to a page with iframes that you are trying to load? I am not seeing that behavior in my testing. Did you update to something other that “” in the code?

  3. Hi Mike,
    Great stuff, I enjoy and appreciate your blog and video posts.

    Working with the demo files I’ve installed the php scripts (same server) at the following paths; /HTTPServer/htdocs/php/ and /HTTPServer/htdocs/httpsRoot/. When I call the scripts https://<>/fmi/webd/php/auto-login.php?, I receive a “Database Not found error”. When I type the response DB URL in manually, it returns the db just fine. Any idea what I’m doing wrong? Also, are there any considerations on the permissions for the php files.

  4. This auto-login.php works great for me, except that the homeurl parameter does not work.
    I just uncommented your line and changed the URL, but it still returns to the Claris page.

    I am using FM19 client and server.

    $data[‘homeurl’] = “”;

    Any thoughts on why this may not work?

    1. Yes, I have noticed this with FMS 19 at least. Instead of specifying as a POST parameter, move just the homeurl to the action parameter of the form element, passing it as query string. Like the following:

      action=”<?php echo $url; ?>?homeurl=”

  5. Just upgraded to FM19.4.2 and this method, which was working fine up until 19.4.1, no longer redirects the user back to the specified homeurl parameter. I have updated the new jwpc_prefs options for 19.4.2 and homeurlenabled and customhomeurl but still this does not redirect the user back to the homeurl on ending a web direct session. The initial login STILL does work however so there appears to be something wrong on Claris’s end. Can anybody validate that the homeurl method works in 19.4.2?

      1. More homeurl woes with 19.4. Time timeout redirect is working, however it only works the first time a user is logged out due to inactivity. Subsequent timeouts redirect the user to the standard WebDirect landing page.

        For example, on first navigation to my site the user ends up with the absolute url of the server + the homeurl parameter in their address bar (eg. https:///fmi/webd/Client%20Portal?homeurl=https:///fmi/webd/Client%20Portal).
        On the first timeout, the user is successfully redirected back to the client portal however the homeurl parameter is missing (eg. https:///fmi/web/Client%20Portal). On subsequent timeouts the user is directed to the /fmi/webd landing page.

        1. It sounds like you should redirect back to a html page that will send them back into a session with the correct homeurl parameter.

  6. Hi Mike.

    Is there a way to customize the error pages also so that they follow the same theme of the custom login or display an error message that is user friendly.

    Many times, solutions are hosted, and an error occurs (such as an openJDK issue, or a database not available) and the user is confused.

    For example, HTTP Status 503 – The end user has no clue what this means and in many cases does not report it to the dev ops team.

    1. Hi Aly,
      That would be dependent on the platform you deploy on and changing the default error pages in either the IIS or apache configuration.

Leave a Comment

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

Scroll to Top