Professional InfoPath 2003 [Electronic resources] نسخه متنی

The Security Model

Internet Explorer implements security zones that allow you to control the level of access given to your computer by the Web sites that you visit. InfoPath uses some of these zones to determine the level of access that forms can have to system resources.

InfoPath users can set security levels, which also will apply to Internet Explorer, by choosing Tools→Options and clicking the Internet Options button.

The levels and the result of these settings for InfoPath are summarized in the table.

Cached Forms

In general, InfoPath forms run in a cached location that is denied access to critical system resources. Cached forms are identified by a URL or a URN. This identification determines the Internet Explorer security zone permissions they inherit.

URL-based forms are the default method of deployment when publishing a form. URL-based forms are said to be sandboxed, because they have restricted access to system resources, and other potential areas of risk. These forms inherit their security permissions, as well as their specific access rights such as cross-domain access, from the Internet Explorer security settings applicable to the original location of the form template.

InfoPath templates stored on a Web or SharePoint server run in the Internet or Local Intranet zones. Forms identified by a URL are cached to the user’s computer, allowing for offline use of the form.

The URL is specified in the publishUrl attribute of the xDocumentClass element in the XSF file. publishUrl is set automatically when a form is published or deployed using InfoPath’s design mode. When you open a form, InfoPath checks if the form has been moved from its original location. If the form template is moved from its original location, no new forms can be created based on that form template, unless this attribute is changed to the current location.

<xDocumentClass
   publishURL="http://someplace.net/forms/"
   .
   .
</xDocumentClass>

Cached forms that are identified by a URN using the name attribute inherit their permissions from the Local Machine zone, which is equivalent to the Trusted Sites zone. This type of form will have access to system and cross-domain resources, but users will be prompted to allow it every time that access is attempted.

Enabling Trusted Forms

If you need to give your users fuller access to system resources in a secure manner, you should consider using trusted forms. Trusted forms are those that are allowed full access to system resources and have a higher set of permissions than sandboxed forms. Form code can use external objects to access resources, ActiveX controls that are not marked as safe for scripting, and business logic provided by COM components.

You may also need to use a trusted form if you intend to make more than limited use of scripting. The InfoPath OM implements three levels of security that define how and where a member may be used, and each topic in the Object Model Reference specifies the level applying to the member. The levels and access permissions are as follows:

0. No access restrictions

1. Reserved

2. Access by forms running in the same domain as the currently open form, or trusted forms

3. Access by fully trusted forms only

Several OM members are set to security level 3, including key methods such as Open, PrintOut, and SaveAs.

You can enable or disable trusted forms in design mode by going to the General tab of the Options dialog box and checking the rather long-winded option starting with Allow . . . in the security options section. See Figure 10-1.

Before you can enable trusted forms, you must first enable submission, which we describe later in this chapter.

Figure 10-1: Setting the trusted form option.

Trusted forms also use URNs as identifiers. Perhaps you’ll recall from Chapter 3 that in the form definition file, the xDocumentClass element has a requireFullTrust attribute. If this attribute is set to “yes”, the form is a fully trusted form. Again, the name attribute must contain the URN.

<xDocumentClass
   name="urn:metadata:newsline"
   requireFullTrust="yes"
   .
   .
</xDocumentClass>

In the XML template file, you must also change the href attribute in the mso-infoPathSolution processing instruction to match the URN name.

<?mso-infoPathSolution
   solutionVersion="1.0.0.156"
   href="urn:metadata:newsline"
   productVersion="11.0.5531"
   PIVersion="1.0.0.0"?>

Registering Trusted Forms

Trusted forms must be registered on the client computer by an installation program or script so that they can be granted a higher level of permissions. In this case, the form gets the same permissions as an application running on the local machine.

Script

You can create a custom installation program by using the RegisterSolution method of the InfoPath ExternalApplication object to install the fully trusted form.

expression.RegisterSolution(ByVal bstrSolutionURL As String,[ByVal bstrBehavior As String="overwrite"])

bstrSolutionURL is a required string value that specifies the URL of the template (XSN) or the form definition (XSF).

bstrBehavior is an optional string that specifies how the template is to be installed. If the form has already been registered, and default value of “overwrite” is used, the registration record will be overwritten. The other valid value, “new-only”, will return an error in the same circumstances, so you can provide for inadvertent replacement.

One approach is to create a script:

oFInstall = new ActiveXObject("InfoPath.ExternalApplication");
oFInstall.RegisterSolution("D:\\Newsline\\metadata.xsn");
oFInstall.Quit();
oFInstall = null;

Another is to use the more robust Microsoft Windows Installer. You should use the RegisterSolution method in any case.

If you need to remove a fully trusted form, you should use the related UnregisterSolution method.

expression.UnregisterSolution(ByVal bstrSolutionURI As String)

bstrSolutionURI is a required string value that specifies the URI of the template. If the template can’t be unregistered, the method returns an error.

Form Registration Tool

InfoPath SDK form registration tool is a command-line utility that simplifies the production of a trusted form and installation program. The file in the SDK Tools folder is RegForm.exe.

To use the tool, start a command prompt and enter the path to the tool, then type RegForm followed by the command-line switches you need. By default, the tool creates a JS file and a BAK file in the same folder that contains the form template that you are converting. The script file can be used to install the fully trusted form. The BAK file is a copy of the original form template.

The example uses the U, V, T, and MSI switches to output a file named metadata.msi.

RegForm /U urn:metadata:newsline /V 1.5.5.3 /T Yes /MSI M:\newsline\metadata.xsn

Installing and Removing Trusted Forms

If you use a script for installation, you need to send all your users both the script and the template files. The script will register the form based on its location on the users’ machines, so you must be sure that it uses the correct folder name.

If you use the RegForm tool to create a JS file for installing a fully trusted form, it will generate a dialog box that asks the user to confirm that they want to register the form, and final dialog box that confirms that the registration was successful.

To use an MSI installation, you need only distribute the MSI file. The MSI installer contains the form template file and automatically registers the form from the folder in which it is installed. A wizard guides the user through the process.

When trusted forms have been installed, they appear on the Custom Installed Forms tab in the Forms dialog box.

Security Best Practice

In the Security Guidelines section of the InfoPath Developer SDK, you will find best-practice advice from Microsoft. We recommend that you read these guidelines carefully and keep them in mind when you design your forms. Also bear in mind that InfoPath is closely related to the model of Internet Explorer, and be sure to keep abreast of any developments in this area that might impact InfoPath.