14.4 Using Additional Form Fill Policy Options

This section discusses some of the different items you can include in a Form Fill policy. This section explains the following Form Fill options:

14.4.1 Using Other Form Fill Tags

The following is a list of the tags that were not described in Section 14.2.1, Basic Components of a Form Fill Policy.




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:

  • Stage. The value for Stage is Fill | Post. Fill applies to building the page. Post applies to the data that is processed and returned.

  • URL. The URL of the original page.

  • Policy. The policy name. Unknown if no policy is found.

  • Error. The decimal error number, like -811.

  • Class. The subsystem that had the error, such as NSSS for SecretStore or LDAP for LDAP problems. See the sys:system\nls\err*.cfg for a list of possible errors.

  • Define. The corresponding #define in the source code.

  • Description. A human readable form of the detected error. The CFG files contain more information.

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.


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.


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.


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:


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.

14.4.2 Injecting Static Values

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:


The following example illustrates how to supply multiple values:


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.

14.4.3 Submitting Form Data to the 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.

14.4.4 Using JavaScript in Forms

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.

JavaScript Examples

   <title> Login Page </title>

   <h1 align=”center”> Login Page </H1>
   <script language=”JavaScript”>
      function setCookie(){
      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;

   <form name=”mylogin” action=”form3.php” method=”POST”
               onsubmit=”setCookie()” >
   <table border=”1” cellpadding=”4” cellspacing=”4”>
      <td><input type=”TEXT” name=”username” size=”30”/></td>

      <td><input type=”PASSWORD” name=”password” size=”30”/></td>

      <td>LDAP Server IP:</td>
      <td><input type=”TEXT” name=”ldap” size=”30”/></td>

      <td colspan=2 align=center>
         <input type=”submit” value=”Login” onclick=”return validate();”>

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:

         <input name=”username” value=”~cn”>
         <input name=”password” value=”~”>
         <select name=”ldap” value=”~”>

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(){
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;

Another way to include JavaScript code in a form is to use the setCookie function only, as in the following example:

   function setCookie()

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(){

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:


14.4.5 Using Login Pages in Multiple Language Character Sets

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:

   <title>Untitled for ASCII</title>
   <meta http-equiv=”Content_Type” content=”text/html;charset=iso-8859-1”>

Example Two:

   <meta http-equiv=”content-type” CONTENT=”utf-8”>
   <title>Untitled for UTF-8</title>

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:

  1. Verify that the back-end Web application, which handles the login credential, supports the UTF-8 format.

  2. 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.

14.4.6 Specifying Form Fill Switches

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:




Enables or disables the enhanced protection on Novell SecretStore data. An administrator typically has read and write access to users’ data. When Enhanced Protection is enabled, the administrator can write data to SecretStore, but he or she cannot read the data.

  • 0 disables Enhanced Protection on SecretStore data
  • 1 enables Enhanced Protection on SecretStore data

Default: 1


Enables Form Fill debugging as the specified level:

  • 0 enables standard SSO output
  • 1-5 enables debugging output, with each higher level providing more information.

Default: 0


Enables or disables the logging of Form Fill debugging information.

  • 0 disables logging of Form Fill debug information
  • 1 enables logging to the Logger screen
  • 2 enables logging to the Extended log file
  • 3 enables logging to both the Logger screen and the Extended log file

Default: 0


Scans the forms for select and input tags for attribute values that iChain saves. iChain then scans the page tags to ensure that it writes out the correct attributes. This is usually required when you have multiple <form> sections with <select> tags on a page.