This section discusses some of the different items you can include in a Form Fill policy. This section explains the following Form Fill options:
The following is a list of the tags that were not described in Section 14.2.1, Basic Components of a Form Fill Policy.
|
Tag |
Purpose |
|---|---|
|
<errorRedirect> |
Must be inside the <action></action> tags. In the event of an LDAP or NSSS error, the user is redirected to the specified URL with the following query string parameters:
For example if the specified URL is http://server/sample_URL/error.html, the user is redirected to http://server/sample_URLerror.html?Stage=%s&Url=%s&Policy=%s&Error=%d&Class=%d &Define=%s&Description=%s If this tag is not used and an LDAP or NSSS error is encountered, the user is presented with the standard iChain error page with corresponding information. |
|
<javaScript> |
Retains JavaScript from the original page. Individual functions can be listed for retention, or the entry can be left blank to retain all JavaScript in the page. For an example of the <javascript> tag, see Section 14.4.4, Using JavaScript in Forms. |
|
<scriptForPost> |
Works in conjunction with the JavaScript function and specifies additional functions to be executed prior to the posting of the form. For an example of the <scriptForPost> tag, see Section 14.4.4, Using JavaScript in Forms. |
|
<LocalPolicy> |
Because the buffer read limit in Form Fill is 50 KB, iChain lets you store additional Form Fill Policies on the local file system of the iChain machine. Syntax: Add the following to the Form Fill Policy on the ISO object:
<LocalPolicy>{Filename}</LocalPolicy>
NOTE:If {FileName} does not contain a slash (\ /) or a colon (:), it is expected to reference a file in the sys:etc\proxy\appliance\config\user\formfill directory; otherwise, iChain reads the information as an absolute path. Multiple <LocalPolicy> tags can be included, but the maximum size of the resulting Form Fill policy is limited to 1 MB. This tag can appear anywhere in the policy, and is not limited to a particular section. |
You might want to inject static values to the data of a POST request or to the URL of a GET request. This can be done using the <injectStaticValue> tag in your Form Fill policy. Multiple values can be separated with the ampersand (&) character. The <injectStaticValue> tag is a subelement of the <urlPolicy> tag.
IMPORTANT:You cannot specify a static value for the value attribute. The following <input> example does not work.
<input type="text" name="city" value="Provo">
The following line illustrates the valid way to inject a static value in a Form Fill policy:
<injectStaticValue>city=Provo</injectStaticValue>
The following example illustrates how to supply multiple values:
<formCriteria>string</formCriteria>
<injectStaticValue>
A=b&C=def&city=Provo
</injectStaticValue>
In this example, three separate values are injected:
The value of “A” is set to “b”.
The value of “C” is set to “def”.
The value of “city” is set to “Provo”.
Injected data overrides any values entered by the user, or any data stored in the ichainFormFillCrib, the SecretStore, or retrieved from the user object via LDAP.
NOTE:Data supplied with the <injectStaticValue> section is not visible in either the original HTML page (when storing data upon first access to a page), or in the source of the HTML page generated by a <debugPost/>. This data is only injected when the request is sent from iChain to the origin server.
Form data is sent to the origin server using one of two HTTP methods: POST or GET. The method used is specified in the <FORM> tag of the original HTML page, and must match the method required by the back-end application that receives the data (the URI specified in the ACTION attribute of the <FORM> tag). These methods have the following effects:
POST: With the POST method, the form data set is included in the body of the form and sent to the URI listed in the ACTION attribute. The POST method is used for applications such as database modification or subscription to a service. This is the most common method of submitting data.
GET: With the GET method, the form data set is appended to the URI specified by the ACTION attribute with a question mark (?) as separator, and this new URI is sent to the server. The GET method is not as secure as POST. It is best used with single responses, such as a single text box.
For complete information regarding HTML form directives, see the HTML specification for Forms.
NOTE:iChain Form Fill only supports the application/x-www-form-urlencoded encoding type (enctype). The multipart/form-data enctype is not supported. For more information, see TID 10090327.
Many Web pages include JavaScript to validate data and set values in the form. Form Fill provides the <javaScript> tag for including JavaScript for form processing.
If JavaScript is validating or completing form fields before submitting, you do not need JavaScript in the URL policy. The first time a user goes to a page that needs to be form filled, the user completes the form and clicks Submit. This completes and executes the field values. Form Fill captures and stores this data to use the next time the user accesses the page. When the user opens the page, Form Fill removes all of the JavaScript and creates a new form with all of the data stored as hidden values. It then uses its own JavaScript function to submit the form. Because all of the data was validated and completed the first time the user completed the form, JavaScript is not necessary for Form Fill to submit the form.
Sometimes, the Web page uses JavaScript to set a cookie required by the Web server for the form to be submitted. In this case, you need to include the JavaScript to set the cookie in the URL policy so that Form Fill can set the cookie each time it submits the form.
JavaScript might also be used to set a time stamp that the Web server depends on when the form is submitted.
The JavaScript Examples section provides examples of pages that use the JavaScript tags. The first example sets a cookie before submitting the form. The subsequent examples show how to use the Form Fill JavaScript tags in the URL policy to ensure that Form Fill sets the cookie each time it submits the form.
The following example has two JavaScript functions: Validate and setCookie. You do not need to include the validate function in the URL policy because the data that Form Fill is storing has been validated. It is necessary for setCookie, because the cookie needs to be set each time this form is submitted.
<html>
<head>
<title> Login Page </title>
</head>
<body>
<h1 align=”center”> Login Page </H1>
<script language=”JavaScript”>
function setCookie(){
document.cookie=”myCookieName=myCookieValue”;
}
function validate(){
if(document.mylogin.ldap.value.length == 0){
alert(“You must provide the IP address of the LDAP server you
wish to login to!”);
return false;
}
return true;
}
</script>
<form name=”mylogin” action=”form3.php” method=”POST”
onsubmit=”setCookie()” >
<center>
<table border=”1” cellpadding=”4” cellspacing=”4”>
<tr>
<td>Username:</td>
<td><input type=”TEXT” name=”username” size=”30”/></td>
</tr>
<tr>
<td>Password:</td>
<td><input type=”PASSWORD” name=”password” size=”30”/></td>
</tr>
<tr>
<td>LDAP Server IP:</td>
<td><input type=”TEXT” name=”ldap” size=”30”/></td>
</tr>
<tr>
<td colspan=2 align=center>
<input type=”submit” value=”Login” onclick=”return validate();”>
</td>
</tr>
</table>
</center>
</form>
</body>
</html>
To include JavaScript code that can be used by Form Fill, use the XML <javaScript> tags.
One way to include JavaScript is to include nothing between the <javaScript></javaScript> tags, as in the following example:
<urlPolicy>
<name>forms3</name>
<url>form.formfill.com/dtest/login.php</url>
<javaScript>
</javaScript>
<scriptForPost>
</scriptForPost>
<actions>
<fill>
<input name=”username” value=”~cn”>
<input name=”password” value=”~”>
<select name=”ldap” value=”~”>
</fill>
<post/>
</actions>
</urlPolicy>
This URL policy results in all JavaScript code contained in the original form to be included with the form submitted by Form Fill as shown in the following example:
<script language=”JavaScript”>
function setCookie(){
document.cookie=”myCookieName=myCookieValue”;
}
function validate(){
if(document.mylogin.ldap.value.length == 0){
alert(“You must provide the IP address of the LDAP server you wish
to login to!”);
return false;
}
return true;
}
</script>
Another way to include JavaScript code in a form is to use the setCookie function only, as in the following example:
<javaScript> function setCookie() </javaScript>
This example shows how to include only the setCookie function by putting the setCookie function name in between the JavaScript tags. Remember to include the function keyword in the tags. The page displays the following result:
<script language=”JavaScript”>
function setCookie(){
document.cookie=”myCookieName=myCookieValue”;
}
</script>
The <javaScript> tag lets you include only the JavaScript from the original form with the form that Form Fill submits. To actually execute the JavaScript code, you must use the <scriptForPost> </scriptForPost> tags.
In the example URL policy, the <scriptForPost></scriptForPost> tags appear just below the <javaScript></javaScript> tags. When you include the <scriptForPost></scriptForPost> tags without any code in the middle, the JavaScript function specified in the onsubmit field of the original form tag executes before the form is posted. In this case, the setCookie function executes just before Form Fill submits the form, which is the desired behavior.
This ensures that the setCookie() function is called regardless of when it is called in the original form. Additionally, you can supply custom JavaScript code that does not appear in the original document inside the <scriptForPost> tags. For example, you can omit the <javaScript> tags from the URL policy and put only the code found inside the setCookie function directly in the <scriptForPost> tags:
<scriptForPost> document.cookie=”myCookieName=myCookieValue”; </scriptForPost>
You can use many character sets in an HTML form. However, Form Fill supports only ISO-8859-1 and UTF-8. The ISO-8859-1 character set is mainly for single-byte characters. The UTF-8 character set is for double-byte characters.
NOTE:The UTF-8 ASCII character sets are the same as ISO-8859-1.
The following examples show how the HEAD element should appear in a form:
Example One:
<head> <title>Untitled for ASCII</title> <meta http-equiv=”Content_Type” content=”text/html;charset=iso-8859-1”> </head>
Example Two:
<head> <meta http-equiv=”content-type” CONTENT=”utf-8”> <title>Untitled for UTF-8</title> </head>
When you use a character set that is different from these examples, such as shift-jis, or ISO-2022-jp, you need to do the following:
Verify that the back-end Web application, which handles the login credential, supports the UTF-8 format.
Change the charset to UTF-8 and save the form in the UTF-8 format.
NOTE:If the content of the title is in Japanese, it should be added after the META declaration as in Example Two above.
For more multiple language character set options and information about changing the backend Apache server to use UTF-8, see the Technical Information Document (TID) 10090464.
When Form Fill is enabled on the iChain box, the sso.nlm file loads automatically. No command-line options are supplied, and all default option values are used. If you want to load the sso.nlm file with options every time the system starts, add a “load sso” statement to the end of the sys:\system\ap_start.ncf file with the appropriate options.
The sso.nlm file can be loaded re-entrantly, so the user can also change the current options from the command line (ICS_SERVER: prompt).
The following table lists and defines the sso.nlm switches that you can apply when loading iChain: