Client settings

You can customize the following client settings:
Enable HTTP compression (Web-only)
Select this box to use HTTP compression to reduce the number of bytes being transferred between the HATS runtime, which is running on the WebSphere® Application Server, and the user's browser. This reduces the transfer time between the HATS runtime and the browser (which improves response time) and reduces the number of bytes flowing in the network (which improves network utilization).
Note:
  1. To determine if compression is working properly and to see before and after page sizes in bytes, you can enable tracing by updating the trace.UTIL line in the runtime.properties file (or runtime-debug.properties file if running in debug mode in the HATS Toolkit). For example: trace.UTIL=7. For more information, see Runtime properties files. In the trace file, search for the runtime.filters.CompressionFilter trace entries. For example: 
    +--------------------------------------+
Text UTIL runtime.filters.CompressionFilter.doFilter()
 17.50.10.140 11/27/06 Servlet.Engine.Transports : 1
enable compression: true 0000CBAx-81SRWWVmQfQ8-_47oK:-1

+--------------------------------------+
Text UTIL runtime.filters.CompressionFilter.doFilter()
 17.50.10.140 11/27/06 Servlet.Engine.Transports : 1
size before: 25315 0000CBAx-81SRWWVmQfQ8-_47oK:-1

+--------------------------------------+
Text UTIL runtime.filters.CompressionFilter.doFilter()
 17.50.10.140 11/27/06 Servlet.Engine.Transports : 1
size after: 4264 0000CBAx-81SRWWVmQfQ8-_47oK:-1
  2. This feature is not applicable when running the HATS application on WebSphere® Portal Server.
  3. HATS ensures the "Accept-Encoding" HTTP header contains "gzip" before compressing a page.
  4. You must restart the application server if you want changes made to compression-related settings picked up while the application is running on the server.
  5. JavaScript™ (.js) and cascading stylesheet (.css) files are not compressed by this new function. You must configure HTTP compression within your HTTP server to provide compression for these types of files. See the documentation of your HTTP server for more information.
  6. This setting can only be specified at the project level. It cannot be specified for individual transformation JSPs
  7. If you are migrating projects from HATS 5.0.x, 6.0, or 6.0.1 you must manually update the web.xml file with appropriate tags. See Special migration considerations for more information.
Enable Minify JavaScript Feature (Web-only)
Select the check box to enable the minify JavaScript file feature on the HATS project. The minify JavaScript feature will remove the unnecessary code contents like code comments and extra space (formatting), convert variables into shorter variables and so on, without affecting the processing of the resources by the browser in HATS.
Note:
  1. If ‘Compress default javascript’ option is selected, then it will compress the HATS default JavaScript file, which is under the below HATS project folder : 
    \Web Content\common
\Web Content\common\hatsdojo
\Web Content\common\scripts
\Web Content\hatsadmin\scripts
  2. If ‘Compress all javascript’ option is selected, then it will compress all the ‘HATS JavaScript files which are located at the below ‘HATS project’ folder: 
    \Web Content\
  3. Users who do not want to get compressed javascript file, can set the property, ‘avoidCompressJS’, in the Source tab of Project, to manually mention the names of the JavaScript files with relative path in value (separated by comma (,)). (Already compressed or minified JS file names (abc.min.js) must be given in values to avoid being compressed again, as they are already compressed). For example: 
    <setting name="avoidCompressJS" value="\bootstrap.min.js,\common\bidishape.js"/>
    After selecting these features, while doing an ‘Export project’, a dialog box showing the ‘Compress JavaScript progress bar’ will be displayed and the process of compression for the javascript file will begin as per the given options.
  4. In a workspace, if a system crash, IDE crash or an abnormal condition occurs during a JavaScript compress process, the javascript files which already got compressed are reverted back to their original stage in the same project with the same workspace by default, when the IDE is restarted. system will take care to revert back original file in same project. (The crash recovery of the project to the original stage will occur only if at least one file related to that project is open at the time of system crash, for which, an ‘export project’ operation is being carried out by enabling the compress JavaScript option).
  5. If an error is displayed on the console for a javascript definition or declaration during the Compress operation, then all the errors should be fixed for the file before re-running the export project operation. An Example of Error during Compress operation is shown below: 
    INVALID_OCTAL_LITERAL. This style of octal literal is not supported in strict mode. at lxgwfunctions.js line 53 : 15
    The Compress operation of the javascript file has failed due to an error in one of the javascript files. Correct those JS and re-run the export project.
  6. This feature is applicable when running the HATS application on a WebSphere Portal Server.
Enable same origin policy protection (Web-only)
Select this box to prevent CSRF attack on the HATS, which is running on a HATS supported application Server, and the user's browser. This will discard the request that is originated from a URL that has no protocol, or request originated from an unauthorized origin/website.
Note:
  1. To protect against CSRF attack, declare the HATS running URL as the ‘param-value’, in web.xml under the ‘HatsCSRFValidationFilter’ section, for param-name= target.origin. For example: 
    <param-value>http://localhost:9080/Test/entry</param-value>
  2. To determine if the CSRF validation is working properly, uncheck the box in client setting and attempt a CSRF attack. This will now allow the modification of HATS data by a different source. The same operation will not be allowed from a different origin, if the client setting check-box is selected.
  3. This feature is not applicable when running the HATS application on a WebSphere Portal Server.
  4. The application server must be restarted for the changes made to origin policy-related settings to be picked up while the application is running on the server.
  5. After enabling origin policy, the default URL, /entry, /hatsadmin/admin , /index.jsp and the default project context path ( http://localhost:9080/Test/ ) will be secure from CSRF attack if the origin policy is enabled.
  6. Users can customize to secure more custom URLs. If a user has added a new servlet, then it has to be configured in web.xml file, as shown below to secure it from a CSRF attack.For example: 
    http://localhost:9080/Test/transfer
   <filter-mapping>
			<filter-name>HatsCSRFValidationFilter</filter-name>
		  <url-pattern>/transfer</url-pattern>
   <filter-mapping>
  7. Users can enable multiple origin sources by adding the source list as the ‘param-value’ while configuring, under the filter ‘HatsCSRFValidationFilter’ section, against param-name = source.origin. For example: 
    <param-value>http://hats:9081/index, http://hatsapp.com/, http://citi.com</param-value>
  8. For users migrating projects from HATS version V8.0.x, V9.0.x, manual update of the web.xml file is required with appropriate tags. See Special migration considerations for more information.
Enable token based protection (Web-only)
Select this box to prevent CSRF attack on the HATS, which is running on a HATS supported application Server, and the user's browser. This will discard the request even if the attacker is able to bypass the same origin policy.
Note:
  1. To determine if the CSRF validation is working properly, uncheck the box in client setting and try a CSRF attack. This will permit the modification of HATS data by a different source, if the ‘Enable same origin policy’ option is unchecked. The same operation will not be allowed from a different origin, if this check-box is selected, and if an attacker is able to bypass the origin policy, then a token based protection will not allow to modify HATS data by CSRF attack.
  2. This feature is not applicable when running the HATS application on a WebSphere Portal Server.
  3. The application server must be restarted for the changes made to token based settings to be picked up while the application is running on the server.
  4. Token based check, when enabled, will secure the default URL /entry, /index.jsp and the default project context path from CSRF attack, and if the origin policy is enabled then /entry, /hatsadmin/admin , /index.jsp and the default project context path ( http://localhost:9080/Test/ ) will be secured from CSRF attack.
  5. Users can customize to secure more custom URLs. If a user has added a new servlet, then it has to be configured in web.xml file, as shown below to secure it from a CSRF attack, and has to add the INPUT HIDDEN FORM field name HatsCSRF in the respective jsppage and the value can be appended by the HatsCSRFValidationFilter token..For example: 
    http://localhost:9080/Test/transfer
   <filter-mapping>
			<filter-name>HatsCSRFValidationFilter</filter-name>
		  <url-pattern>/transfer</url-pattern>
   <filter-mapping>
<INPUT TYPE="HIDDEN" NAME="HatsCSRF" VALUE="">
  6. For users migrating projects from HATS version V8.0.x, V9.0.x, manual update of the web.xml file is required with appropriate tags. See Special migration considerations for more information.
  7. If both of the protection features have been enabled, then unknown sources cannot modify HATS data, and if an attacker is able to bypass the same origin policy, then the token based protection will restrict the modification of HATS user data.
Suppress sending unmodified fields Web-only
Select this box to specify that HATS should not send modified input field data to the host when the contents of the field are identical to the data supplied by the host.

Clear this box to specify that HATS should send modified input field data even when the contents of the field are identical to the data supplied by the host. For example, if the host filled a field with ABC and the user typed ABC into the field, the typed data will be returned to the host.

Note:
This setting can only be specified at the project level. It cannot be specified for a single transformation JSP.
Enable XSS Policy protection (Web-only)
In the web.xml file, provide the below instructed value to protect against XSS attack on the HATS, which is running on a HATS supported application Server, and the user's browser. This will discard XSS attack.
Note:
  1. To protect against XSS attack, in the web.xml file, under the filter ‘HatsHeaderSecurityFilter’ section, update the ‘param-value’ from “NO” to “YES”. Listed three policies can be enabled and disabled independently by giving respective value “YES” or “NO”.
    • "Content-Security-Policy"
    • "X-Content-Type-Options"
    • "X-XSS-Protection"
    The policies are disabled by default. For example: 
       <param-value>YES</param-value>
  2. To determine if the XSS validation is working properly, set the ‘param-value’ to “NO” in web.xml ‘HatsHeaderSecurityFilter’ section
  3. This feature is not applicable when running the HATS application on a WebSphere Portal Server.
  4. The application server must be restarted for the changes made to XSS policy protection-related settings to be picked up while the application is running on the server.
  5. Users can customize to secure more custom URLs. If a user has added a new servlet, then it has to be configured in web.xml file, as shown below to secure it from an XSS attack.For example: 
    http://localhost:9080/Test/transfer
   <filter-mapping>
			<filter-name>HatsHeaderSecurityFilter</filter-name>
		  <url-pattern>/transfer</url-pattern>
   <filter-mapping>
  6. For users migrating projects from HATS version V8.0.x, V9.0.x manual update of the web.xml file is required with appropriate tags. See Special migration considerations for more information.
Include protected, read-only labels in default tab order (RCP-only)
Select this box to specify that the default tabbing order of fields on the transformation view should include protected, read-only fields.

Clear this check box to specify that the default tabbing order should not include protected, read-only fields.

Enable automatic field advance
Select this box to specify that when a user completely fills an input field with data, focus automatically advances to the next input field.
For Web applications, you can selectively disable this function for an individual transformation by adding the following lines just after the </HATS:Form> tag in the transformation file. To selectively enable the function specify true instead of false. 
<script> 
autoAdvance = false;
</script>
For rich client applications, you can selectively disable this function for an individual transformation by overriding the needsAutoAdvanceSupport method on the individual transformation as shown below. To selectively enable the function return true instead of false. 
public boolean needsAutoAdvanceSupport(boolean preferredValue) {
return false;
}
Note:

For DBCS considerations when using this setting see Enable automatic field advance.

Include host and non-host input fields
Select this box to specify that when auto advance is enabled, focus automatically advances to the next input field in the order of the input fields on the transformed screen without regard to the order of the input fields on the host screen.

Clear this box to specify that when auto advance is enabled, focus automatically advances to the next input field in the order of the input fields on the host screen.

Initial cursor position
The position of the host application's cursor normally controls the initial input focus location for your screen transformation. In some limited cases, it might be desirable to have the host application's cursor location ignored, and instead give the initial focus to the first item on the transformation. This is intended for highly-customized transformations where the order of host input fields has been changed. With this feature enabled, the initial focus placement will be the first item on the screen transformation rather than the input field containing the host cursor.
Note:
  1. The Initial cursor position setting does not appear in the GUI as a configurable setting. It must be set in the source of the transformation file.

    For Web applications, you can enable this feature for a transformation by adding the following lines just after the </HATS:Form> tag in your transformation: 

    <script> 
initialInputFocusFromCursor = false;
</script>
    For rich client applications, you can enable this feature for a transformation by overriding the isInitialFocusAtCursorPosition method on the individual transformation as shown below. 
    public boolean isInitialFocusAtCursorPosition() {
return false;
}
  2. Be certain to test your transformation carefully. Many host applications rely on the cursor position for proper behavior. For example, a macro button placed on a transformation may cause the invoked macro to begin entering data in the wrong location on the host application, since the cursor may be in a different location than expected.
nextFieldForDropDown (Web-only)
Use this setting to specify that the cursor position be moved to the next input field when a selection is made from a drop-down list. The default for new projects created in HATS V7.5.0.2, or later, is true. The default for projects created before HATS V7.5.0.2 is false.
Note:
  1. This setting does not appear in the GUI as a configurable setting. It must be set in the source of the application.hap file as shown below. 
    <class name="com.ibm.hats.common.RuntimeSettings">
         <setting name="nextFieldForDropDown" value="true"/>
</class>
  2. This setting is effective only when Enable automatic field advance is selected.
Overwrite mode (initial)
Select this box to initially enable overwrite mode. If enabled, text entered into an input field overwrites text at the cursor position one character at a time. If not enabled, text entered into an input field is inserted at the cursor position pushing existing text ahead. The user can toggle from this initial setting using the Insert key.
Note:

For DBCS considerations when using this setting see Overwrite mode (initial).

Select all text on focus
Select this box if you want all text in a field to be selected when the field receives focus, which is typical behavior for a Web application. Clear this box if you want no text selected when the field receives focus which is typical behavior for a terminal emulator.
Note:
  1. For Web applications:
    • The default is selected.
    • This setting does not affect the Overwrite mode (initial) setting behavior.
    • This setting is only valid when Internet Explorer is used as the browser for the application.
  2. For rich client applications:
    • The default is cleared.
    • When selected, this setting functions like the Overwrite mode (initial) setting in that characters are overwritten as a user types into the field.
    • Text is selected only when the keyboard is used to tab into the field. Text is not selected when clicking the mouse in the field.

  3. For DBCS considerations when using this setting, see Select all text on focus.

Enable busy page (Web-only)
Select this box to display a busy-page message when multiple requests are submitted by the user before processing has completed on the initial request. Clear this box if you do not want a busy-page message displayed. If cleared, you cannot submit any more requests until the server returns a response.
Enable transformation refresh (Web-only)
If the user used any custom HATS template in an existing HATS project, the user must wrap the “hatsDiv” tag around the transformation tag in the template to avail “transformation refresh”.
Users must select this box to refresh only the transformation area, if not enabled it refreshes the entire page.
By default, the box will be disabled.
Note:
For non-en languages except Japanese, a user must wrap the "hatsDiv" tag around the transformation tag in a template to avail "transformation refresh."
Enable arrow key navigation (RCP-only)
Select this box to allow use of the up, down, right, and left arrow keys to navigate to non-protected host fields on the rendered screen. If the Rendering tab, Field widget, Allow cursor positioning on protected fields setting is also selected, the arrow keys can be used to navigate to both non-protected and protected host fields. This is typical behavior for a terminal emulator application. Clear this box if you do not want to allow use of the arrow keys for navigation.
You can selectively disable this function for an individual transformation by overriding the needsArrowKeyNavigationSupport method on the individual transformation as shown below. 
public boolean needsArrowKeyNavigationSupport(boolean preferredValue) {
return false;
}

To selectively enable the function return true instead of false.

Note:
  1. Navigation is always based on host field positions, not on the UI position of a field.
  2. When this function is used in conjunction with screen combinations, the algorithm to calculate the next input field will first attempt to navigate to an appropriate field from the same screen as the current field. If an appropriate field does not exist, the next screen (based on the ID of the screen) will be searched to find an appropriate input field.
Enable type-ahead support (RCP-only)
Select this box to enable type-ahead support. If enabled, the user can begin typing data intended for input fields on the next screen (or screens) sent by the host, before they are received and processed by HATS. As the next screen (or screens) are received, HATS sends the previously typed data (type-ahead data) including any keys that submit the input to the host.

If screen customizations exist for these screens, all actions defined in the customization are executed, including applying transformations. However, the type-ahead data is not actually placed into the rendered transformation before being submitted to the host. Instead, it is sent directly to the host as previously typed, bypassing the transformation completely. In this manner, this functions much like a terminal emulator's type-ahead support. What this means to the user is that type-ahead data must conform to what each native host screen expects, not what the applied transformation expects.

If you clear this box, the Type-ahead field setting is cleared in Operator Information Area on the Rendering tab. For information about displaying the type-ahead data in the operator information area, see Type-ahead field.

Note:
  1. Only host aid keys along with their host data, for example, userid[tab]password[enter], and host navigation keys, for example, tab and home, can be typed ahead.
  2. Application keys and commands, for example, the Disconnect command, which is the default command for the key sequence CTRL+D, cannot be typed ahead.
  3. Key remapping at the RCP Runtime Extension plugin level is supported for host keys and commands in type-ahead mode.