14.6. Using Browser-Based Forms

One of the most anticipated new features introduced with InfoPath 2007 and MOSS is the ability to gather data using browser-based forms. This capability greatly extends the reach of electronic forms because users are no longer required to have the InfoPath client application installed in order to fill out a form. With InfoPath Forms Services enabled, they can edit many forms directly in their web browser.

Although there are many limitations to the functionality of browser-based forms, they are essential for many critical business solutions. Figure 14-23 shows the sample expense report form open in a web browser.

Although there is a lot of power and value in using browser-based forms, the true intention of this feature is to extend the reach of forms that would otherwise not be available to a significant number of users. It is not intended to replace client-based forms. To get the most benefit from the Forms Services layer, you can create two views within your form—one for the browser and another for the client.

Figure 14.23. Figure 14-23

With a little planning, you can achieve good results by designing your forms for both environments and then disabling the client-only views when the form is displayed in the browser and vice versa. An example of this approach might be a form that retrieves the information needed to generate a medical patient summary document using Open XML. The form would gather the core data elements for a patient record and then generate the summary document based on the information entered into the form. The browser-based version would only collect basic information using string fields, while the more enhanced client version would use dropdown lists populated directly from SharePoint sites and the like.

This is just one example, but the introduction of browser-based forms generally creates more complexity for the developer. This is partly due to the restrictions that are placed on forms that can be presented in the browser. The first thing to consider when developing browser-based forms is whether your existing forms are compatible with presentation in a browser. InfoPath 2007 provides a lot of help in making this determination by including a fairly sophisticated design checker that searches for and flags compatibility issues that it finds in a given form.

In general, browser-based forms are limited in the following ways:

• You cannot use JScript or VBScript.

• You cannot create custom task panes.

• You cannot use repeating sections in a master/detail relationship.

• You cannot include placeholder text in controls.

• You cannot merge forms using custom code.

• You cannot implement custom save or submit code.

• You cannot digitally sign the entire form. Only sections can be signed.

Another area of concern is what to surface to the user when a form is presented in the browser. You have a good deal of control over what happens by using the Browser category of the Form Options dialog, as shown in Figure 14-24. However, once you enable a form for display in a browser, many of the other options are affected, as shown in Figure 14-25.

Figure 14.24. Figure 14-24

Figure 14.25. Figure 14-25

14.6.1. Configuring InfoPath Forms Services

InfoPath Forms Services (IFS) is included with MOSS and can also be installed as a separate product. You configure IFS from the Application Management page of the Central Administration web site. The basic configuration options have mostly to do with security and authentication. Many of these options are only necessary because there are so many combinations of features that tend to subvert the security policies that have been put in place by administrators. For example, it is possible for users to upload form templates and then make them browser-enabled. This might go against an organizational policy that requires all forms to be opened on the client. From the IFS administration page, an administrator can enable or disable this feature and choose the desired authentication behavior for all forms deployed to the farm.

14.6.2. Managing Form Templates

Given the ability to gather data via browser-based forms, there is a separate interface that system administrators can use to upload and manage the form templates that are available on the server. Once a form template has been successfully uploaded to the server, it can then be hosted in web pages within a site collection.

The problem with centrally managed form templates is that there may already be instances of the form already in use. This carries implications for what should be done about outstanding data-gathering sessions as well as what to do about future sessions. This problem is exacerbated by the fact that browser-based forms are typically used as part of long-running processes, also known as workflows.

For example, if a workflow starts out using version 1 of a modification form and then that form is upgraded to version 2 while the workflow is hibernating, then problems could arise when the workflow wakes up and the upgraded modification form tries to manipulate the version 1 data. Since there is no way to predict all of the scenarios where this type of conflict can occur, it is left to the administrator to sort it out. This is done from the Upload Form Template page, shown in Figure 14-26.

Figure 14.26. Figure 14-26

14.6.3. Handling Forms Authentication

Consider the case of an InfoPath form that needs to communicate with a remote server to retrieve data for a dropdown list. It does so by supplying user credentials directly to the server, which authenticates the user and returns the result. When that same form is uploaded to IFS, a problem is created because an extra level of indirection is introduced. This is called the double-hop or multi-hop delegation problem.

This is not an issue when using Kerberos authentication because the user's credentials are embedded inside a Kerberos ticket, which IFS can then use to authenticate the form on the user's behalf. NTLM authentication, on the other hand, requires that the encrypted credentials pass directly between the requesting process and the server. Since the IFS server is not running in a process associated with the form user, the required credentials are not available when the form is loaded, and therefore the form cannot be authenticated in response to the user's request.

Microsoft recommends Single Sign-On (SSO) as the preferred method for dealing with the double-hop problem. SSO is an encrypted database of user credentials that act like a Kerberos ticket without requiring Kerberos authentication protocols. Using SSO, IFS can retrieve the required credentials without risking exposure of those credentials to unauthorized users.