You can’t always go Back
Using WebDirect is a powerful way to bring your FileMaker application to an audience beyond FileMaker Clients. Allowing users to access the FileMaker application through their web browser. There are a few tips and tricks for deploying your application in WebDirect, making the experience almost as good as the native client experience. First, is linking directly to records and layouts within the application. And second is preventing the use of the back button which logs the user out of the WebDirect session. Last, we will discuss a recent upgrade to FileMaker server 19.3.2 that provides another tool for sharing FileMaker content online.
Using Deep Links
Deep Links allow developers to provide a link to a specific web resource. When you share a link to a specific news article, you are providing a Deep Link that goes directly to the article. This experience is much better than linking to the news homepage and expecting the user to then search for the article that was shared.
The WebDirect home page is located at http(s)://<host>/fmi/webd/, and displays all the available WebDirect applications. Or, a link to a specific application would be http(s)://<host>/fmi/webd/<database name>. Normally, when a user logs in through WebDirect, they are taken directly to the application home screen. There is also a way to provide additional context as query parameters in the web link, which FileMaker can use to navigate the user to a specific layout, a specific record, and perform a specific action.
The syntax of a web link contains multiple components. WebDirect recognizes several parameters in the query portion of the link that developers can use to their advantage; “script”, “param”, and $<variable>. These parameters allow the developer to construct a link that 1) Performs a specific script ( after the onFirstWindowOpen script triggers, 2) Send the specific script a parameter, and 3) Set specific variables for the script context. Let’s look at an example.
http://<host>/fmi/webd/Personnel?script=Open¶m=Record_Link&$_recordID=79&$_layout=HomeIn the example above, the link will take the user directly to the login screen for the application, “Personnel” ( the “.fmp12” is optional ). If the application is set to login using an account under File Options, this screen will be bypassed and the user will go directly into the application. If set, the onFirstWindowOpen script trigger will run, and the script “Open” will be run next. The parameter “Record_Link” will be sent to the script, “Open”, and when it runs, the variable $_recordID will already be set to 79, and $_layout set to “Home”. Now the script has enough information to go to layout “Home” and find record ID 79, immediately after logging the user in.
iCore recommends using a single, deep link point of entry script. Once the link is handed out, that link is hard coded, and changing the script name, or the parameter or variable formats will prevent the link from working anymore. If the script name is changed from “Open” to Open File”, the links will stop working. It is best to us a single, URL encoded and unchanging script name, specifically for handling this deep link functionality.
For this reason, when running scripts from a web link, it is also better to standardize script parameters on JSON. JSON is a standard human readable text format for passing multiple parameters into a script. For additional information about using JSON formatting, view this support article on working with the JSON Functions. In the above example, the JSONSetElement function can be used to capture the same information contained in the parameter and the variables:
$param = JSONSetElement ( “”;
“[‘Record_Link’][‘recordID’]; 79; JSONNumber ];
“[‘Record_Link’][‘layout’]; “Home”; JSONString ] )By parsing the JSON in the “Open” script, all of the necessary information is contained in a single parameter. For an added layer of protection, use the HexEncode function to ensure that all parameter data can be URL encoded. Just remember to use HexDecode ( Get ( ScriptParameter ) ) before parsing the parameter.
HexEncode ( $param )Deploying your application in WebDirect
WebDirect works differently than a simple web page. Users are actually using WebDirect as a thin client into the application, and all the programming is taking place within a single session of a FileMaker WebDirect “web page”. This can easily lead to confusion for the user based on their experience navigating most other websites. For instance, when the application takes the user to a new layout, they may want to go back to the previous layout by pressing the web browser back button. This muscle memory is extremely tempting for the user. However, in WebDirect, this has the effect of logging the user out of the application session and over to the WebDirect home page. The web browser Refresh button has the same behavior, but the user is typically less likely to utilize that button in WebDirect.
One thing the developer can do to prevent the Back button is to “wrap” the WebDirect session within a web page, and prevent the back button from doing anything from there using javascript. The implementation of this feature is quite easy, assuming there is access to the server file structure. The default web server root is located here:
- Windows: [drive]:\Program Files\FileMaker\FileMaker Server\HTTPServer\conf
- macOS for HTTP URLs: /Library/FileMaker Server/HTTPServer/htdocs
- macOS for HTTPS URLs: /Library/FileMaker Server/HTTPServer/htdocs/httpsRoot
- Linux for HTTP: /opt/FileMaker/FileMaker Server/HTTPServer/htdocs
- Linux for HTTPS: /opt/FileMaker/FileMaker Server/HTTPServer/htdocs/httpsRoot
iCore has created an index.html file that can be placed in the root folder which detects when the back button is pressed in the web browser and displays a customized alert warning the user that the back button is disabled for this application. This alert is only active while they are within the WebDirect session on this server, and stops once they navigate away to another website. This index file is available for download, and can be forked on GitHub. Share your issues and suggestions there to improve the file.
It also performs a couple of other functions. First, it automatically redirects to the default WebDirect home page. Users who navigate to http://<host>, will automatically redirect to http://<host>/fmi/webd/. Second, it adds another query parameter that can be passed through in a deep link, “db.” This allows the developer utilizing deep links to shorten the URL.
http://<host>/fmi/webd/Personnel?script=Open¶m=Record_Link&$_recordID=79&$_layout=HomeAfter reformatting and hex encoding the JSON parameter, becomes:
http://<host>?db=Personnel&script=Open¶m=7B225265636F72645F6C696E6B223A7B226C61796F7574223A22486F6D65222C227265636F72644944223A37397D7DThe parameter is passed directly to the Personnel application, and the Open script is run after logging in. The script parameter can then be hex decoded, and parsed into variables.
Data API and Persistent Links
Another great integration with the web browser is being able to send a link to download a file held in a container field for a specific record. Until recently, a direct way to do this was to expose XML for the application, and use the record ID and a specific layout with the container field on it, to allow a user to download the file from their browser. Unfortunately, the record ID is an internal value FileMaker uses, is not immediately available outside the record context, and is not persistent across record imports or syncs.
When FileMaker implemented the Data API, a bug allowed developers to access a link to the container data which could be sent to users that could download a file directly. This was a problem from a security standpoint, because users downloading the file were not verified through FileMaker security, it was like allowing the [Guest] user into the application. Claris put out an update that fixed this security hole so that the URL expires after 2 hours. FileMaker developers complained, because the feature was so useful. Now, Claris has released update 19.3.2 and has made the feature able to be turned on or off from the Admin API. Unfortunately it is not available through the admin console, but it will be available through the iCore Control application download. The setting is located under Connectors > FileMaker Data API, under Container Authentication only for servers running 19.3.2.202 or greater. To create persistent links using the Data API, turn off Container Authentication.
WebDirect, Simple Browser Access
WebDirect is a great client for non-developers. Users don’t have to maintain a certain version of FileMaker on their desktop, because WebDirect always uses the current server version. There are a number of script steps that aren’t compatible with WebDirect, or are only partially supported, so the developer will have to take care to address any of these differences. Also, formatting can be slightly different in WebDirect, and even different depending on the browser. These minor challenges are outweighed by the benefits of having a dependable client for your applications in the ubiquitous web browser.
Do you have any video of that? I’d love to find out some additional information.
Very nice article. I absolutely love this site. Keep writing!