Building a Database-Driven Web Application With FileMaker Edward L. Ford November 26, 2006 Summary: This document discusses techniques for incorporation into the design of a FileMaker database that will be used as the storage mechanism for a dynamic website or web-based application, including using FileMaker s built-in security mechanisms to secure the database from unauthorized access through a website. This document has also introduces the FX.php framework that enables PHP to communicate with FileMaker Server Advanced in order to retrieve and store data in a FileMaker database.
Outline I. Introduction a. Software Requirements b. Developer Requirements II. Diving In: The FileMaker End a. Design Principle #1: Security is Paramount! b. Design Principle #2: Limit the amount of data PHP needs to process III. The PHP Side of a FileMaker Web Application a. FX.php b. Connecting FX.php to the FileMaker Server c. Querying the Database, Handling the Results IV. References / For More Information
Building a Database-Driven Web Application With FileMaker Introduction What benefits are there to integrating FileMaker with a website? With a static, HTML website, someone must edit the webpage manually to reflect updated information every time anything changes. Some organizations maintain multiple web pages that contain the same information, with each document serving a different purpose. The problem with such a system is that information must be updated in two, three, or more places every time any change in the data occurs. Such duplication of data is unnecessary. Using a FileMaker database, data can be stored in a single location, and then shared across multiple web pages. Updating the database once allow changes to propagate across all web pages using that data, eliminating the work of keeping multiple sources of the same data up to date. FileMaker Server has two mechanisms for publishing data to the Internet: Instant Web Publishing (IWP) and Custom Web Publishing. Instant Web Publishing is just that instant. Setup requires only one step: turn on the IWP option in the database. IWP attempts to mimic the look and feel of the FileMaker desktop software as closely as possible in a web browser. Layouts accessed through the web browser look identical to layouts in the FileMaker Pro software. However, in my own experience, I find IWP more problematic than useful: many mouse clicks are needed to accomplish the simplest of tasks, complex layouts are sluggish to load, and the layouts do not match the design or feel of existing websites. The other option, Custom Web Publishing (CWP), is an XML scheme for accessing the data in the database without the overhead of a user interface. Instead, PHP can use the XML produced by CWP to build sophisticated web applications that go far beyond the capabilities provided by IWP.
This document is designed to help individuals understand the basic legwork necessary to create a FileMaker driven website. It highlights basic considerations and setup procedures one should think about when planning a web application with FileMaker integration. This document is not a tutorial for configuring a FileMaker Server, nor is it a PHP, XML, or how to build a web application tutorial. There are plenty of freely available resources on the Internet for assistance with those questions. Software Requirements FileMaker Server Advanced 7.0+ FileMaker Pro 7.0+ Web Server with PHP 4.2+ It is important to note that a FileMaker-web solution requires FileMaker Server Advanced The basic FileMaker Server does not contain the CWP module necessary for web deployment. Further, FileMaker 7.0 or later is recommended for developing a web application. It is possible to use earlier FileMaker versions, but the enhancements in FileMaker 7.0+, most notably in security measures, make it the best choice. The remainder of this document assumes at least FileMaker 7.0. Developer Requirements Anyone looking to deploy a web-based FileMaker solution should have at least an intermediate level of experience in building FileMaker databases and solutions. In addition, developers should have familiarity with web site development, with a basic understanding of HTML and JavaScript. Familiarity with PHP is handy for developing solutions from scratch, but FMWebSchool has products available to generate the necessary PHP code for you please see the References at the end of this document for more information.
Diving In: The FileMaker End Planning is key to making development of a FileMaker web application painless. Before building the website, the FileMaker database should be completely thought out and built. Consider all of the possible needs the database will fill, and plan the fields, value lists, and layouts accordingly. Once the database is built, test it rigorously, and ensure that its design will meet the needs of your end users. Fix all initial design flaws now, as it will save time and headaches later. Website access to your database is governed through the layouts in the database. Data streams from the server based on which layout you request the data from. Layouts should use FileMaker s access control to enforce security of the data in the database. Design Principle #1: Security is Paramount! Limit what your website can access with Privilege Sets and User Accounts. Turn off unneeded Extended Privileges, like FileMaker Mobile. Common sense dictates that every database, no matter how trivial the information it contains, should require a strong password for access. No user account should have access to areas of the database not needed for the account s intended purpose. FileMaker provides a good way of restricting accounts through Privilege Sets and User Accounts use them. If the web application is one where users log in with a FileMaker user name and password, I ll assume appropriate access controls have been established for the user accounts, making the next few paragraphs irrelevant. However, if the web application or website is available to the public (i.e. without a log in), a general use account for the web application should be used. Securing a database for web access this way involves defining a new Privilege Set and a new User Account, described below.
First, set up a Privilege Set that limits access to only the layouts, scripts, and data fields the web application needs. To do so, analyze what access the website needs by asking some basic questions: What can a visitor do with the data? Are they allowed to edit the data? Are they allowed to make new records? Delete records? Or do my website visitors only need to view the data? What data fields does the website need to access? On a field by field basis, should this field s data be accessible, and if so, is access read only, or read-write? What layouts contain those data fields determined above? Are there certain scripts that the website needs, or will the web application work without access to FileMaker scripting functions? After answering these questions, making the privilege set should be simple. While creating the privilege set, take the time and limit the Extended Privileges available to the web application, again, for security. Web applications only need the XML Access (fmxml) extended privilege to function. (Advanced web applications may also need the XSLT Web Publishing privilege too, but only turn it on if you absolutely need it). Since this privilege set is for the web application, do not allow other types of extended privilege access. For more information regarding the Extended Privileges, consult the FileMaker documentation (see the References at the end of this document). Once the website privilege set is established, a User Account that uses the privilege set must be established. As always, it is important to specify a strong password on all user accounts an account for a web application is no exception. To summarize, a system of privileges now exists to limit what visitors can do with data form the FileMaker database. But if this is a public website, how will visitors know the user name and password to use? The website user name and password are stored in a PHP variable which cannot be seen by visitors the details of this are covered later in this document.
When developing a database-driven website, data security must be the first consideration. It is temping to define loose privilege sets or loose account restrictions to simplify the development process. The risk to data being stolen by loose security restrictions cannot be ignored. The risk is great. Take the time to design the database from the ground-up with security in mind. It is much easier to include security immediately than it is to add it later. You will thank yourself later for doing it right the first time. Design Principle #2: Limit the amount of data PHP needs to process Every time a website queries a FileMaker layout for data, FileMaker returns the data for every field on the layout. If the data needed is only a small portion of the data returned by the FileMaker server, PHP is doing significant extra overhead work to process the unneeded data. This overhead will make any webpage with excess data load slowly. Less overhead = less to process = happier (and quicker) servers. Thus, layouts accessed by the web application should be trimmed to provide only the needed data. One way of trimming a layout quickly is to take the layouts used by users of the FileMaker Pro desktop software and duplicate them. Then, remove the unneeded fields from the duplicate layout. In databases with a large number of layouts, it might be helpful to append a prefix such as web- or www- to the duplicated layout s name. Doing so groups all web-application layouts together alphabetically, and flags their intended purpose clearly. Verify that the web application s privilege set has appropriate access to these layouts. Also, modify other privilege sets to prevent all other users from accessing the web-only layouts. At this point, you should have two sets of layouts: one set for the users of the FileMaker Pro desktop software, and the other set exclusively for your web application.
The PHP Side of a FileMaker Web Application The database design is complete, tested, and has well thought out security restrictions. Now what? It is finally time to build the web application. FX.php First, you should understand the flow of data between the different points in the system: FileMaker Server Advanced FX.php PHP / Web Server End User s Browser FX.php is the PHP framework that makes a FileMaker-driven website tick. Data flows to and from FileMaker in XML format, with FX.php acting as the translator between XML data and the web application. The remainder of this document uses PHP code examples with FX.php. If you are not familiar with PHP, investigate the products by FMWebSchool, which can generate the PHP code automatically for you. Formatting conventions: For simplicity, FX.php will be referred to as FX from here forward. PHP code will be set in a typewriter font, with any information that needs to be changed for your specific application displayed in bold. Connecting FX.php to the FileMaker Server The first thing your web application needs to do is establish a connection to the FileMaker server. PHP files needing access to the FileMaker server should have the following lines: include_once( server_data.php ); $Query = new FX($serverIP, $webcompanionport, $datasourcetype); $Query->SetDBData($databaseFile, "LayoutName"); $Query->SetDBUserPass ($webun, $webpw);
This code creates a variable named $Query, and links it to FX with all of the information needed to connect with the FileMaker server. Since the information needed to connect to FileMaker is reused often, it is best to define the values in a separate file, like server_data.php. This way, if any of the connection information changes, only one location needs to be fixed. The file server_data.php might look like the following: <?php $serverip = 'filemakerserver.website.com'; $webcompanionport = 80; // for version 7+, this should we the web server port $datasourcetype = 'FMPro7'; $webun = 'Web Username'; $webpw = 'Web Password'; $databasefile = 'Filename.fp7'; $scheme = 'http'; // generally this will be 'http'; 'https' for SSL connections?> Querying the Database, Handling the Results Once the code to talk to the FileMaker server is established, common database actions, such as adding a new record, editing a record, or searching, can be appended to the $Query variable to perform an action. Example that performs a search: $Query->AddDBParam( FileMaker Field Name, Value You Are Searching For ); $Results = $Query->FMFind(); //For more info on FMFind()and other related FileMaker operations, // see the FX documentation This example search for the specified data values and stores the results of the search in a variable called $Results. $Results is a large associate array containing info about the results: the number of records found, their internal FileMaker record numbers, as well as the data itself. From the contents of $Results, data can propagate the web application as needed. From this point forward, developing the web application is strictly PHP application development, which is beyond the scope of this document.
FX provides many different commands that create the basic building blocks of interacting with the FileMaker Server. If you download FX from the author s website, there are PDF files included in the download that document all of the FX commands, as well as details on the structure of the $Results variable above. He also provides the database and PHP source code for a small example web application playing with this example and its code is a valuable learning tool. Finally, the creator of FX hosts a subscription email list on his website to provide help using FX. I have used this list to solve my own problems when working with FX it s an excellent resource. References / For More Information FX.php website, http://www.iviking.org/fx.php/: Example web application and a helpful mailing list Official PHP website, http://www.php.net: Complete explanation of PHP s functions FMWebSchool, http://www.fmwebschool.com/: Has products to assist in developing FileMaker web applications FileMaker s documentation, manuals, and best practice guidelines, http://filemaker.com/support/downloads/index.html