5.5 Error Codes for XML

5.4 Security on the Web

The security of your web-published databases is very important, so those considerations will be discussed here. You have several options for setting security on your databases through Web Companion. You can use passwords and associated access privileges to control access to databases published on the web. You can use the Web Security database to control access to your web-published databases.

These options are set in the Web Companion Configuration dialog. The Web Security database option is not available until you have that database open. The configuration dialog is part of the FileMaker Pro application and is available by choosing Edit, Preferences, Application and selecting the Plug-Ins tab. Select the Web Companion plug-in and click on the Configure button. The configuration dialog is shown in Figure 5.12. If you cannot configure Web Companion, go back and check the setup of TCP/IP and other suggestions listed earlier in section 5.16, "Web Companion Setup".

Figure 5.12: Web Companion Configuration dialog

Password access and the Web Security Database provide the same protection with a few exceptions. Both have password protection, field security, record security, and allow the creating, viewing, editing, and deleting of records. Script calls are either allowed or disallowed by the Web Security Database but restricted by privileges if FileMaker Pro access privileges are used. Additional features for the Web Security Database are user name verification, finding in a specific field, and remote administration.

5.41 Security with Web Companion

The document Web Security.pdf, found in the Web Security folder of the FileMaker Pro folder, is a useful document discussing access privileges vs. Web Security Database, field-level and record-level security with the Web Companion plug-in, the Web Security Database, and general web security tips. This document is titled "Using the Web Security Database" in FileMaker Pro. An updated version of this document is installed with FileMaker Pro 5.5 or FileMaker Pro 6 and is titled "Securing data on the Web." The main difference is the record-level access available in FileMaker Pro 5.5 and greater security in FileMaker Pro 6.

Get the latest version of FileMaker Pro to ensure that security issues have been optimized. You may be able to update the Web Companion plug-in for your particular version by itself. Check the FileMaker, Inc. web site for updates, http://www.filemaker.com/support/updaters.html. Also, check for specific Web Companion reports on the following web site: http://www.filemaker.com/support/webcompanion.html.

5.42 Security vs. Security Blanket

There are methods that are secure, and there are methods that give the user a good sense of comfort but are not really secure. Both are discussed here. Do not discount the user experience of a security blanket. A cover is still a cover and few may attempt to lift it. The look of your web pages can be enhanced with the security blanket methods as well. Hiding some of the coding or HTTP requests can be less confusing to the user. Use both methods wisely to enhance the experience for both yourself and your users.

Security Blankets

Some of the methods for providing a security blanket are to place a default page in all web folders, use frames to hide the HTTP requests, redirect back to a main page with JavaScript, and use forms to hide the HTTP requests. Other methods for providing a security blanket are to prevent search engine robots from indexing pages and to prevent or clear browser caching of pages. There may also be other methods that are not more secure but merely provide a sense of security.

Place a Default Page in Web Folders

The Web folder, found in the FileMaker Pro folder, is the default location for files used by Web Companion. The default folder can have subfolders and still be used by Web Companion. You can also use other folders in different directories and on different servers. All folders whose permissions allow read have contents available. Pages and files available for read can also be copied to another computer. A directory or folder without a default page may list all the files in that directory, but including a default page in all folders will prevent this. The topic "About creating a custom home page", found in FileMaker Help, discusses a default page when using Instant Web publishing, but the advice is valid for any web-published databases.

If the Web folder does not have any files, add one called index.html, index.htm, default.html, or default.htm and select it in the Home Page pop-up of the Web Companion Configuration dialog. This file can be very simple and include only base information along with a link back to the main page of your web site. By default, if no page is specified when linking to a site, one of these files will be used. This prevents users from seeing a list of your files in any folder where your index or default page resides. A simple default page is shown in Listing 5.28. You can also create a redirect, as shown in Listing 5.29, back to your main page. If the browser does not support the redirect, include the link.

Listing 5.28: Sample default.htm

 <html> <head> <title>MyDomain</title> </head> <body> Please return to the <a href="http://www.mydomain.com/mainpage.htm">      main page</a>. </body> </html> 

Listing 5.29: Sample redirect for default.htm

 <html> <head> <title>MyDomain</title> <meta http-equiv="refresh" content="0;URL=http://www.mydomain.com/   mainpage.htm"/> </head> <body> If your browser does not directly go there, click here to return to   the <a href="http://www.mydomain.com/mainpage.htm">main page</a>. </body> </html> 

Use a Frameset and Frames to Hide HTTP Requests

Creating a web site with frames can hide the full request to a database. The user goes to a main page the first time. This page, in Listing 5.30, sets up the frames, and all subsequent pages will be displayed within a frame or multiple frames. The user only sees the first link, to the main page, in the browser location field. If you want to go outside this frame, to another site for instance, make a link or form call with TARGET="_top". This is only a security blanket, because the browser also allows the user to open any frame in a new window or view the source for the main window or any frame.

Listing 5.30: Request to a database in a frame page

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-frameset.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>Framed</title> </head> <frameset rows="100%,*"> <frame src="/books/3/422/1/html/2/http://yourDomain.com/fmpro?-db=MyDatabase&-lay=web&-format=   -dso_xml&-view" name="main" marginheight="0" marginwidth="0" scrolling=   "auto" /> <frame name="none" marginheight="0" marginwidth="0" scrolling="no"   noresize="noresize" /> </frameset> </html> 

Redirect Back to Main Page with JavaScript

This tip from Lynda LaCour, at Lylac Inc., uses a JavaScript object that gets called when any page is opened. The JavaScript method onload() can be placed in the <BODY> element of the page and will be triggered as the page loads in the browser. If every page includes this onload event and is opened outside of the intended frame, it will take the user immediately back to a main file and frameset. Listing 5.31 shows the main page with a frameset. The user is taken to this page if he tries to view a page outside of the frameset. Include this JavaScript on every page in your web site except the main page:

 <BODY onload="if(parent.frames.length==0)top.location='index.html';"> 

Listing 5.31: index.html

 <HTML> <HEAD> <TITLE>Main Page</TITLE> </HEAD> <FRAMESET ROWS="135,100%" FRAMEBORDER=1> <FRAME src="/books/3/422/1/html/2/NTOP.HTM" NAME=thetop NORESIZE MARGINWIDTH=0 MARGINHEIGHT=0   FRAMEBORDER=0> <FRAME src="/books/3/422/1/html/2/FMPro?-db=myDatabase&-lay=cgi&-format=-dso_xml&-findall"   NAME=thebottom MARGINWIDTH=0 MARGINHEIGHT=0 FRAMEBORDER=0> </FRAMESET> </HTML> 

Use Forms to Hide the Request

Most of the HTTP requests we have used thus far are links using the get method. Form requests can also use the get HTTP method, but the post method is more commonly used. More about forms will be discussed in Chapter 6, "Using HTML and XHTML to Format Web Pages." The form requests are hidden in the browser location field with the post method. This is a security blanket, as the request can still be found in the source of the page. Listing 5.32 is a page containing a form request to "MyDatabase." All of the fields are hidden, and the user will only see the Submit button. The link equivalent is:

 <a href="fmpro?-db=MyDatabase&-lay=web&-format=-dso_xml&-findany">   Show Me!</a> 

Listing 5.32: Request to database using a form

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"   "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-   transitional.dtd"> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>Formed</title> </head> <body> <form action="fmpro" method="post" target="main">       <input type="hidden" name="-db" value="MyDatabase" />       <input type="hidden" name="-lay" value="web" />       <input type="hidden" name="-format" value="-dso_xml" />       <input type="submit" name="-findany" value="Show Me!" /> </form> </body> </html> 

Hide from Robots

Search engines may send out requests to index web pages so that they can be easily listed. This is accomplished with a special program called an indexing robot (or bot). No harm is done unless you do not wish a page to be listed forever. Dynamic pages may or may not be included for indexing. Many robots look for a special page, called robots.txt, in your web directory. If this file exists, it may specify whether a particular directory is to be indexed.

 Disallow: /myPages/ 

Include a meta tag in the head portion of your document to specify whether that particular page is to be indexed or not. In addition, a page may be indexed, but you may not want any links within it followed:

 <HEAD>       <META NAME="robots" CONTENT="index, nofollow" /> </HEAD> 

These rules may or may not be used by any given robot, so even the security blanket does not cover you well. Add these elements if you wish, as they may provide some coverage, but do not rely upon them.

No Cache and Expire Cache

Two other meta tags, which should be sent as the hidden part of any HTTP request, could be included in the head but may be ignored. The first one instructs browsers to expire the page from the browsers' memory after a certain date and time. Dates are to be listed in GMT format. The second meta tag tells browsers not to cache the page. If the user presses the Back button in the browser, the page may be still available but will not be saved if he returns to the same page later. The code below shows both of these meta tags. Browsers do not always comply with these requests, so your results may vary. As with the robot exclusion, use the caching meta tags, but do not rely upon them for security or security blanket coverage.

 <HEAD>       <META HTTP-EQUIV="pragma" CONTENT="no-cache" />       <META HTTP-EQUIV="expires" CONTENT="dayname, day Month year         hour:minute:second GMT" /> </HEAD> 

Security

Better security can be provided by the use of FileMaker Pro passwords along with browser login. Web Companion can be configured to disable Instant Web Publishing and to allow only access from specific IP addresses. Web servers can be configured with permissions to various directories and pages to add another layer of security. FileMaker Pro's network protocol can be limited and the passwords can provide record-level access. If scripts are used with web-published databases, they can be made more secure by the way they are designed. Two FileMaker Pro plug-ins, the Troi-Coding plug-in and the Crypto Toolbox plug-in, can encrypt data that need to be shared but secure.

FileMaker Pro Passwords and the Web

Your first line of defense is to use FileMaker Pro's passwords for webpublished data. You can specify the access privileges for a database in the Define Passwords dialog. Choose File, Access Privileges, Passwords to open the dialog shown in Figure 5.13 or 5.14. One password must be designated to allow all access privileges if you plan to set up additional passwords to restrict privileges. Select the Access the entire file check box and type a master password in the Password field. Passwords are not case sensitive, may be up to 31 characters long, and should have at least six characters in a mix of letters and numbers. Using nonalphanumeric characters may produce unpredictable results in cross-platform usage or when databases are web enabled.

Figure 5.13: Define Passwords dialog, Windows

Figure 5.14: Define Passwords dialog, Macintosh

If you need to restrict browsing, editing, deleting, or creating records, uncheck each appropriate check box for all records and create a new password. New in FileMaker Pro 5.5 and FileMaker Pro 6 is recordlevel access. Select the pop-up menu next to Browse records, Edit records, or Delete records and specify a calculation to limit access. A user restricted to browsing, editing, or deleting only records according to a validation has the same restrictions for web-published databases.

The following documents in FileMaker Pro Help can assist you in setting passwords and access privileges: "Defining and changing passwords" and "General notes about passwords." Notes about limiting access on a record-by-record basis in Help gives some examples and tips on using this feature.

Record-level access is available in FileMaker Pro 5.5 and greater. Any database created using these record-level limitations may be opened with FileMaker Pro 5.0 but will have restrictions. If Browse records is limited or removed in FileMaker Pro 5.5, the database cannot be opened with FileMaker Pro 5.0 with that password. The user cannot delete or edit records when the database is opened with FileMaker Pro 5.0 if Delete records or Edit record (respectively) have restrictions set with FileMaker Pro 5.5. You can open a database with a full access password in FileMaker Pro 5.0, but it will remove any restrictions set with FileMaker Pro 5.5 if you change any of those passwords.

Browser Login Required

If you use passwords or the Web Security database, your user may be asked to enter the password from the browser page. A base web page that does not perform a database action will not display a login dialog, but the first page to perform a database request and return results from an action will trigger the browser login dialog to appear. Figure 5.15 shows this dialog in Netscape 6. The user must complete the login before the action will proceed. This login may specify the database name and the domain name and ask for a user name and password. Incorrect entry will return an error, which you can use to branch to an error display page. After the first request for a database, the user will not be asked to log in again during that browser session. If another file has a different password, the browser dialog will appear again.

Figure 5.15: Web login on Macintosh, Netscape 6

Sometimes the password may be saved in the browser preferences. The login dialog for Internet Explorer is shown in Figure 5.16. The check box for saving this password is in the dialog. Unfortunately, you will not have control over your users' selection of this option. You may wish to caution them against it in any opening pages before they log in. If a password has been saved, it can be deleted from the browser preferences. Security can be compromised if the password is saved and another user has access to the browser on that machine. The login will still be requested with the first database action, but the browser will supply the saved user name and password.

Figure 5.16: Web login on Windows, Internet Explorer 5

The browser asks for a user name and password. The user name need not be completed for the password to be checked in your database. The values for both of these fields are maintained as long as the user is in your site. Any password entered for one database will apply to any other database with the same password. You are asked for the password once if it is the same for every file accessed. The access privileges apply to the highest level for that particular password. If the user leaves your site and returns, he likely will not be asked to enter the password again. He may have to quit the browser and go to your site again to be asked to login. If you set default passwords in your databases, your users will not be asked for a password in the browser.

The user name that is entered in the browser dialog can be used with record-level access. See "Record-level Access" later in this chapter for how you can check this value. The user name is persistent until the user leaves the web site or quits the browser.

Set Permissions on Directories

On some web servers, you can set the directory permission to be read or write only. These can also have passwords set. On UNIX and NT directories, privileges to directories can be read, write, and executable. These privileges can be set to allow owner, group, and all access. Each access can have different privileges. Generally, files and folders inside a protected directory inherit the same protection. This may also need to be specified. Passwords can be set upon these directories. Consult your server documentation for setting up permissions and passwords for UNIX and NT directories. If you are using AppleShare IP or Macintosh OS X, consult the documentation for setting directory permission and passwords.

Permission to access the Web folder is set by the Web Companion plug-in. If you have a database set to sharing with Web Companion, any files within the Web folder are available on the machine with that database. This folder is your root directory used by Web Companion to access files. You can place aliases to these files in the Web folder rather than the files themselves, but they will still be available for access. Any file, including images, shown on a web page can be saved or downloaded. Source can be viewed, revealing information you may not want seen. These files are protected only if you have IP address filtering set in the Web Companion Configuration dialog.

Never store databases in the Web folder. If you must use remote administration, set a password on any databases in this folder. -dbopen and -dbclose only work on databases located in the Web folder.

Disable Instant Web Publishing

If you are no longer testing Web Companion setup, uncheck Enable Instant Web Publishing in the Web Companion Configuration dialog. If Instant Web Publishing is enabled, any file set to sharing with Web Companion will be available simply by addressing it in the browser. Sample calls to web sites with databases are shown below. Any passwords and group access settings you have implemented will also apply to Instant Web-published databases. Disabling Instant Web Publishing just adds another layer of prevention by not making them available to Instant Web Publishing.

 <http://www.mydomain.com/> <http://localhost/> <http://127.0.0.1:591/> <http://123.123.123.123/> 

Set Databases to Multi-User (Hidden) Sharing

Your databases set to sharing with Web Companion may also be available for access through the TCP/IP network protocol. With a fast enough connection, a database can be directly accessed when the Hosts button is selected in the Open File dialog of FileMaker Pro. Figure 5.17 shows this dialog. You can save the entered address by checking Permanently add entry to Hosts list. The next time you select the Host button, this IP address or domain name will be listed. If your network settings in Application Preferences are TCP/IP and the files have Multi-User or Multi-User (Hidden) sharing set, they may be available for direct access.

Figure 5.17: Specify host address to open remote databases

You will want to prevent files from being seen in the Host dialog for security. If you specify the filename with the underscore (_) and select Multi-User in the File Sharing dialog, your database may still be available through TCP/IP. Selecting Multi-User (Hidden) will hide this file in the Host dialog even if your host name or IP number is used. The FileMaker Network Sharing dialog is shown in Figure 5.18. If you use Filemaker Server to host the databases, it can open files set as Single User, Multi-User, or Multi-User (Hidden). Single User files can only be hosted by FileMaker Server if you have enabled Allow FileMaker Server to host Single User files. This option is a part of Server and only available there.

Figure 5.18: Network sharing

"Securing data on the web", the PDF document found in the Web Security folder of the FileMaker Pro folder, states: "It is not necessary to enable FileMaker Pro Multi-User sharing or OS-level file sharing to share Filemaker Pro databases over the Web. It is not necessary to specify TCP/IP as the Network Protocol in FileMaker Pro application preferences. Enable these technologies only if you need them for other types of network access."

If you have Enable Instant Web Publishing unchecked, no database will be listed on a default page, whether you use the underscore in the filename or not. However, they will all be available for Web Companion to use for custom web publishing, including XML publishing, if you have set them for sharing with Web Companion.

You can also prevent databases from being listed on the built-in home page with Instant Web Publishing if they have an underscore (_) as the last character of the filename, excluding the extension. "SECURE_.FP5", "DONTSHOW_", or "nolist_.fp5" are examples of how to use this underscore character.

Including the underscore does not provide additional security. These files simply will not be listed on the default home page for Instant Web Publishing if it is enabled. You can still use these files for custom web publishing by using the full name, including underscore.

Export Privileges Required for Web Publishing

Web Companion requires shared files to have export privileges. Any file shared for web publishing needs to be opened by a password that allows export. Therefore, at least one password other than your master password should have Export Records checked. Files opened by a password without export privileges will produce an error when web published. Be aware, though, that files with export privileges can also allow a user to export data if they have access to your database through TCP/IP.

Remember that files with export privileges can be accessed if you do not include a password! Export privileges provide a means to web publish your data. They also provide a means to export your data.

If you specify related fields on a layout of a shared database and the related file does not have export privileges, those fields are still available for web publishing. If no layout or Layout 0 is specified for web publishing, none of these related fields are available. However, anyone having access to your files can export any field that is related, whether it is on a layout or not.

Do not include secure data, even in related files. Any available data is, well, available! Related fields can be exported from any database with a relationship. If a database allows export, a related file need not have export privileges to be accessed! A related field on a layout is available, even if the related database does not have export privileges or does not have Web Companion sharing enabled.

Exercise 5.2: Create a Browse-only Password

This exercise will set up a file for web publishing with very basic privileges. The user will be able to view the data and search for specific data but will not be able to create, edit, or delete any records. It is assumed that you have Web Companion enabled in FileMaker Pro and you are using self-testing. If you have the files on a network, change all references of "localhost" to the IP address or domain name of your web publishing server. If you require a port number, add that to the address, too.

1. Create a new database called BROWSE_.FP5.

2. Create three fields: ItemID (number), ItemName (text), and ItemDescription (text). These fields may be typical in a catalog or products file. Items for viewing should only be changed by a user with an administrative-level password. Web users will want to search and see the results.

3. Create a layout called web and place the three fields on this layout. See the FileMaker Pro Help topic, "Placing and removing fields on a layout" if you need assistance. The format of the fields, and the font, size, and color do not matter. You will only be extracting the field names and contents with XML results, so the layout can (and should) be very basic.

4. Create three to five new records and enter data into these fields.

5. Create a master password, "master", and a default password, "user", by selecting File, Access Privileges, Passwords. Passwords should follow the guidelines above and include a mix of letters and numbers. Simple passwords are included in these examples for convenience.

6. Select these privileges for "user": Browse Records and Export Records. Also set the available menu commands to None. The browser does not see these menu commands, but should the database be opened through a network, this hides the menu commands, including Export.

7. Set the default password to "user" by selecting Edit, Preferences, Document. Check Try default password and type user into the box. This will not ask for a password when the file is opened. You will be asked to enter a password in the browser, however.

8. Launch your browser and enter this URL: http://localhost/ fmpro?-db=BROWSE%5f.FP5&-lay=web&-format=-dso_ xml&-findall. Notice that the underscore (_) is changed to (encoded as) "%5f". -db=BROWSE_.FP5 will also work.

9. You will be asked to enter a user name and password. Enter user for both and continue. The results will be similar to the following:

    <?xml version="1.0" encoding="UTF-8" ?> <FMPDSORESULT xmlns="http://www.filemaker.com/fmpdsoresult"> <ERRORCODE>0</ERRORCODE> <DATABASE>browse_.fp5</DATABASE> <LAYOUT>web</LAYOUT> <ROW MOD RECORD>       <ItemID>1234</ItemID>       <ItemName>Red Ball</ItemName>       <ItemDescription>Bouncy ball, soft enough for baby to         hold.</ItemDescription> </ROW> <ROW MOD RECORD>       <ItemID>1235</ItemID>       <ItemName>Paper Airplane Kit</ItemName>       <ItemDescription>Book with patterns for folding different         paper airplanes.</ItemDescription> </ROW> <ROW MOD RECORD>       <ItemID>1236</ItemID>       <ItemName>Teddy Bear</ItemName>       <ItemDescription>Cuddly, stuffed bear with t-shirt.         </ItemDescription> </ROW> </FMPDSORESULT> 

10. Remove "&-lay=web" from the URL and see what results you get. If you have created any other fields, these will be listed, as well as the three on our web layout. When you do not specify a layout, the default Layout 0 (or all the fields in this database) is available.

11. Close this file and open it again while holding down the Shift key on Windows or the Option key on Macintosh. When you are asked for a password, type the word master in the dialog.

12. Quit your browser to clear your user login and then relaunch it. Enter the same URL as above (with or without the layout specified). Even with the database opened by the main password with all access privileges, you are asked to enter a password in the browser. If you use the master password, you have all privileges. If you use the user password, you only have browse and find privileges.

13. Create a new blank password with the same privileges as the user password. Change the Document Preferences to auto-enter the blank password (clear this field).

14. Close the BROWSE_.FP5 database and open it again. You will not be asked for a password to open this file. You have set the blank password to be entered for you.

15. Quit your browser again to clear the login and relaunch. When you enter the same URL, you will not be asked for a password. If you try to perform any action other than to view or find, you will be asked to enter a user name and password for the browser login.

The lowest level password setting is the blank password with Browse, Export privileges, and limited menu commands. If you use this password as auto-enter in your Document Preferences, the user will not be asked for a password if the file is web published and the action is to browse or find. If no layout is specified, all fields and their contents in the file are available to the user.

Warning 

The "browse-only" access level still allows scripts to be performed! If you want data to be available for searching and viewing only, do not include any scripts in the file with this password. Scripts will perform based upon privileges set. For example, if you do not allow delete privileges, that script step cannot be performed.

The document "TechInfo #107663" found at http://www.filemaker.com/support/techinfo.html states that using a (no password) can compromise your security. If you must use this so that your user does not have to log in, create it as the first password in the Define Passwords dialog. See "FileMaker Pro Passwords and the Web" earlier in this chapter for information about creating passwords. Check for the latest version of FileMaker Pro, as this may be fixed in a future revision.

Record-level Access

New in FileMaker Pro 5.5 and FileMaker Pro 6 is record-level access for browsing, editing, and deleting. This access is set in the Define Fields dialog and uses a Boolean calculation to determine if a record is to be displayed or not. A find request for records will omit any record that has a false result in the calculation. Any valid calculation can be used to check a user login, access group, or date, for example.

If you request a browser login, the user name entered in that dialog can be used to identify a set of records. The browser remembers the login name until the user quits the browser. Web Companion can recall the name and place it in a field. It can also test for the presence of that login name when searching, viewing, editing, or deleting records. Create a field called webUser and have it auto-enter this value. If you check for this field in your requests, the user will be prevented from seeing records that do not match the login name.

 External("Web-ClientName", 0) 

For more examples using record-level access, see the FileMaker Pro Help topic, "Notes about limiting access on a record-by-record basis." Web Companion usage of record-level access is also covered in "Securing data on the web." This document is installed in the Web Security folder with FileMaker Pro, and reminds you that global fields, unstored calculations, and summary fields may still be displayed. Record-level access will not include restricted data in a summary field.

Assign Groups

Assign groups in FileMaker Pro and use the function Status (Current-Groups) at the beginning of your script to decide whether to proceed or not. Create your passwords before creating groups, as they are closely tied together. Use the database created in Exercise 5.2 to add group access in Exercise 5.3. This file should have (no password) as the default password. The database will open automatically and no browser login will be requested. Remember that this password only allows browsing and finding records. We want to limit the fields available even if no layout is specified and the request is to find all records.

Exercise 5.3: Assign Access Groups to Web-Published Databases

1. Open the Browse_.fp5 database, created in Exercise 5.2, with the Option key (Macintosh) or Shift key (Windows) held down. This will bring up the password dialog. You need to enter the master password to change group access settings.

2. Open the Define Groups dialog by selecting File, Access Privileges, Groups.

3. Enter none into the Group Name field and click the Access button. This dialog is where you select the passwords and fields that are assigned to each group. The access privileges can be set to Accessible, Not accessible, and Read only.

4. Note here that layouts can be selected for access but will be ignored by web-published databases. If you share a database on a network as well as web published, you can change these.

5. Select the group you just created, none. When it is selected, you choose the passwords assigned to it. Leave the master password and (no password) to Accessible, but click on the circle beside user password until it is grayed (Not accessible).

6. Set all the fields to Not accessible, except for the fields ItemDescription, ItemID, and ItemName. Set these fields to Read only. You may not have any fields except these three, so just set them to Read only.

7. Save the group settings and click on Done to close the Define Groups dialog.

8. Close the file and let the default (no password) access open the file.

9. Web publish the database with this -findall command:

    http://localhost/fmpro?-db=BROWSE_.FP5&-format=-dso_xml&-findall=1137 

You will see only those fields with read-only permission.

If you change the action to -new, you will be asked to enter a user name and password in the browser dialog. This is because you only have browse and search permission with (no password) and have limited field access with groups.

Field-level access can be set with groups to add security to password access. If you create several groups, you can add permissions or restrictions based upon the password entered. We used the none group to restrict the field access. If we requested a -new action as above and entered the password master into the browser login, we would have been granted full access to all fields and all actions.

5.43 Script Security

Several script security tips are listed here:

• If you must maintain scripts within your web-published databases, you can use conditional tests to verify the level of access. The function Status(CurrentGroups) will return a list of all the groups attached to the password used to log in. Use this test in an opening script step:

   If [ PatternCount(Status(CurrentGroups), "AccessibleGroupName") ] .. proceed with script... End If 

• Do not allow any Go to Layout scripts. Layouts can be changed in an HTTP request on the web with the -lay parameter.

• Do not allow developer action scripts. Files may have developer scripts to unlock status, for example. If you must include these, provide a check for a password and group access before proceeding.

• Scripts that change or delete data can be called from another database or from an HTTP request if the password allows these privileges.

• Any database with an auto-enter or blank (none) password can be compromised by not setting low-level access.

• Do not use scripts with dialogs requesting response. Regardless of access privileges, these dialogs are not displayed in the browser and will cause FileMaker Pro to halt processing.

5.44 Final XML Web Publishing Thought

Security is a big issue and you should read the Web Security documents from FileMaker. You should set up your networks for the optimum in security to make them as secure as possible. You can also find white papers about security on the FileMaker web site, http://www.filemaker.com. Use encryption, as described here, to transmit your data over the Internet. Whether you make HTTP requests to FileMaker Pro or web publish your databases, consider some of the advice given here.