Java and JavaScript Support

Java Support Through the CIE

Java class files contain compiled Java byte-code which the Java Virtual Machine interprets and executes. When Ivanti Connect Secure encounters this byte-code, it rewrites the compiled Java without decompiling it. The Ivanti Connect Secure new byte-code redirects all HTTP(s) and socket based network communication to an intermediate proxy server via secure HTTPS tunneling. This approach provides a secure and portable proxy mechanism for Web-based client/server applications that utilize client Java applets. The Java rewriting technology is available on the Sun JVM (version 1.4.1+) and MS JVM platform.

The process of rewriting Java code may affect performance. To improve the performance of Java applications, we recommend using the Enable Java instrumentation caching option in the Maintenance > System > Options page of the Ivanti Connect Secure Web console. For more information, see Templates Feature Guide.

Supported Java Classes and Methods

Ivanti Connect Secure supports most network related classes and methods through the Java rewriting engine. In general, as long as the Java applet uses TCP and the network traffic is initiated from the client, Ivanti Connect Secure supports the applet. The following table lists Java classes and corresponding methods that are supported through the Content Intermediation Engine.

The following table lists the Supported Java Classes and Methods:

Supported Java class	Corresponding methods
java.applet.Applet	All methods
java.applet.AppletContext	showDocument
javax.swing.JApplet	All methods
java.net.Socket	All methods
java.net.URL	getHost, getPort, getFile, getProtocol, openStream, openConnection, toString
java.net.HttpURLConnection	setRequestProperty
java.net.URLConnection	setRequestProperty
java.net.InetAddress	All methods
java.lang.reflect.Method	Invoke
java.lang.Class	getResource
java.lang.ClassLoader	getResource, getResourceAsStream
netscape.javascript.JSObject	eval, call, removeMember, setSlot, setMember
msxml3.IXMLHttpRequest	Open
javax.net.ssl.SSLSocketFactory	createSocket
javax.swing.JEditorPane	setPage
com.ms.lang.RegKey	getStringValue, getIntValue, getBinaryValue
java.util.ResourceBundle	getBundle

Unsupported Java Functionality

Listed below are Java features that are not supported through the Content Intermediation Engine.

•Ivanti Connect Secure may not support class files written in a proprietary format. To prevent Java intermediation problems with Ivanti Connect Secure, ensure that all network-related classes conform to the Sun Java specification. If the class files do not contain standard byte code then Ivanti Connect Secure cannot intermediate the content.

•Ivanti Connect Secure does not support Java applets that include a checksum validation verifying that the applet is unaltered. (Ivanti Connect Secure cannot support this type of validation since it alters the applet’s byte code during intermediation.) Instead, you should use the standard code-signing procedures to secure the applet.

•Ivanti Connect Secure does not support Java applets connections that initiate from the server. If the applet contains server-initiated connections through the use of the ServerSocket class, then the applet does not work through Ivanti Connect Secure.

••Ivanti Connect Secure does not support Java applets that make UDP connections.

•Ivanti Connect Secure does not support Java applets that use Java Remote Method Invocation (RMI) Technology.

•Ivanti Connect Secure does not support Java applets that use the Java Web Start architecture (JNLP files).

•Ivanti Connect Secure does not support Java applets that are written for Oracle JVM or IBM JVM.

Code Signing Certificates

Most commercial Java applets that Ivanti Connect Secure intermediates perform privileged tasks. To perform these tasks, the user must accept the certificate that is used to sign the applet. However, since Ivanti Connect Secure modifies the byte-code, the original signature is invalid and Ivanti Connect Secure must re-sign the applet. Ivanti Connect Secure re-signs the applet with a self-signed certificate whose PS is not a trusted root. Due to the use of the self-signed certificate, the browser displays a warning that must be accepted for every launch of the applet. To avoid the frequent security warnings, you need to import a code signing certificate. For instructions, see Certificates.

JavaScript Support Through the CIE

The Content Intermediation Engine handles complex uses of JavaScript, including menu animation, field validation, pop-up windows, frame manipulation, and calendar functions. In addition, the Content Intermediation Engine also supports standard and advanced JavaScript functions such as setTimeout, setInterval, and insertAdjacentHTML. When creating JavaScript content, however, please adhere to the guidelines in the following sections.

Use Straightforward JavaScript

Even though the Content Intermediation Engine is sophisticated enough to handle complex constructs in JavaScript, it may have trouble processing code whose purpose is obscured by multiple levels of indirection. We recommend that you write your code in a straightforward fashion in order to enable the Content Intermediation Engine to capture all the URL references.

Usage of document.write

The Content Intermediation Engine supports the use of document.write. We recommend the following guidelines when using document.write:

•Do not use base href’s in document.write.

•Avoid writing nested script tags in document.write. If you must write nested script tags in a document.write, break the string “<script …” into “<scr” + “ipt….”

•Tags created partially in static HTML and partially in JavaScript are not supported. For example, the following code snippet is not supported. The “textarea” tag is written dynamically using the JavaScript document.write function while the rest is written using static HTML

document.write(“<Textarea> Tag contents") ;

</script>

</Textarea>

Avoid Complicated Constructs in the eval() Function

The server cannot intermediate JavaScript code that dynamically generates and executes on the browser such as the eval() function. Instead, Ivanti Connect Secure inserts a client-side JavaScript parser into the rewritten page in order to parse and rewrite the dynamically generated code. However, the client-side parser is not as sophisticated as the server-side intermediation engine. As a result, Ivanti Connect Secure sometimes accurately rewrites code inside a <script> tag but might not handle the same strings when you pass them through an eval() function. Therefore, complicated constructs within an eval() function may not work as you expect. For Ivanti Connect Secure, window.open() within the eval() function works, but accessing the Document Object Model (DOM) in an eval() function might not work.

Do Not Use Common JavaScript Functions on the Left Hand Side of an Assignment Statement

If the javascript code contains an assignment statement where a function call is in the left hand side of an assignment statement then it is not supported through the CIE engine. For Ivanti Connect Secure, foo.setAttribute("bar") = "false" will not work through the CIE engine.

Do Not Assume Element Numbers or Positions in a DOM

The Content Intermediation Engine supports pages that use the Document Object Model (DOM). When traversing the DOM, however, do not assume the number of elements or the position of the elements. Instead, use criteria such as the ID field of the element to access specific DOM elements (since Ivanti Connect Secure may add content to the intermediated page, thereby invalidating the original number of DOM elements). Web pages that assume the number of elements or position of an element may trample upon or use content added by Ivanti Connect Secure.

For example, if you include five elements on a page, Ivanti Connect Secure may add a sixth element to the DOM. When the Web application then attempts to access and display the last element of the page, it displays the element inserted by Ivanti Connect Secure, which was not the desired intent.

This guideline is especially relevant when using the Ivanti Connect Secure toolbar.

Use One Scripting Language Per Page

Use only one scripting language in one page—do not mix JavaScript and VBScript in the same page. If possible, use JavaScript instead of VBScript since VBScript has no IVElished standard that we can recommend at this time.

In relation to scripting languages, keep in mind that using an empty type attribute in a script tag does not work. For example:

Some JavaScript Code

</script>

Limit Usage of the with command

Limit the use of the command. Excessive usage could lead to incorrectly rewritten pages. For example, instead of using:

with (doc){

location=http://...;

}

use:

doc.location=http://...

Even though the Content Intermediation Engine supports with statement, we recommend that you avoid such statements and use and simpler constructs. Ivanti Connect Secure may not properly rewrite more complicated statements such as nested with statements since it is difficult to distinguish local variable references from property references on an object.

For example:

foo = 1;

is a local variable but:

with (obj) {

foo = 1;

}

In this example, it is difficult to determine if foo is a local variable or a property of obj. Ivanti Connect Secure uses heuristics to trap the common combinations of objects and properties but this practice obviously does not translate to a general solution. For that reason, we recommend that you avoid the use of with.

IFRAME Objects Must Contain an src Attribute

IFRAME objects must contain an src attribute to avoid the secure/non-secure warning. For example, the rendering of the following IFRAME results in a secure/non-secure warning.

var ifrm = document.createElement("IFRAME");

ifrm.id = foo;

ifrm.height = 100;

ifrm.width = 100;

document.body.insertAdjacentElement("bar",ifrm);

Use frames.length Instead of frames[0]

When checking for the existence of frames in a document that may not contain any frames, use frames.length instead of frames[0].

Setting a Cookie and Accessing the Cookie Through JavaScript

A cookie is not available through JavaScript unless the HTML body exists in the response to the page where the cookie was set. That is, if you are setting a cookie in an HTML response and want that cookie to be available in JavaScript, the response body must contain some HTML content.

For example, the following web page will not work:

1.Set a cookie, myURL, on a 302 response.

2.The 302 response does not contain any HTML but contains JavaScript.

3.In the onunload function in the JavaScript, access the myURL cookie.

4.The cookies not accessible.

Understand the Number of Cookies You Can Set

Most browsers have an upper bound on the number of cookies that you can set on the client-side through the use of document.cookie. You cannot use the maximum number of cookies allowed by the browser, however, since Ivanti Connect Secure sets cookies as well.

In most deployments, Ivanti Connect Secure manages configuration information by setting up to four cookies. (Depending on the options chosen by the Ivanti Connect Secure administrator, this number might be smaller.) Therefore, your Web application can set the maximum number of cookies allowed by the browser minus four. Deployments that use the eTrust SiteMinder server, however, must set less cookies, since Ivanti Connect Secure sends cookies to the Web browser to enable single sign-on between SiteMinder and Ivanti Connect Secure.

Use ASCII Characters

To render pages through the CIE engine correctly, avoid non-ascii characters such as ` and ñ in JavaScript.

Selective Rewriting Resource Policy for a POST URL

If the ACTION URL for a FORM POST is being generated on the client-side in JavaScript, a selective rewriting resource policy for the ACTION URL may not work.

To work around this issue:

1.Change the web application so that the ACTION URL is in static HTML. For example,

2.Change the POST to a GET.

Comments in Assignment Statements

Comments inserted in the middle of a right hand side assignment statement in javascript are not supported. For example, the following statement is not supported through the CIE engine.

foo = foo.replace(/class=*/,'').

//replace(/<p [^>]*>/,'<p>').

replace(/ style=\"\"/,'');

Mixing JavaScript and Static Content

Pages where the OBJECT tag or the APPLET tag is partly written in JavaScript and partly as static content do not function well within the engine. To ensure correct functionality write the complete tag through static text or through JavaScript.

Miscellaneous

In addition to the issues outlined in the previous sections, also keep the following guidelines in mind when creating JavaScript content:

•Avoid using variables that indirectly assign URL references to native JavaScript objects using the array format rather than the regular dot format. For example:

document["location"] = "http://www.yahoo.com";

and

var d = document; var l = "location";

d[l] = "http://www.yahoo.com";

Instead, use:

document.location = "http://www.yahoo.com";;

•Do not use HTML and JavaScript reserved words and built-in functions as object names, function names or variable names in your code. For example, do not define and use variables such as top, location, pathname, and domain.

•Ivanti Connect Secure occasionally generates its own JavaScript functions that start with the string Dana. To avoid conflicts with Ivanti Connect Secure JavaScript functions, avoid using DanaXXX as function and variable names.

•Avoid embedding JavaScript in the src attributes of tags. For example:

•Ivanti Connect Secure does not support the use of port in window.location. For example, Ivanti Connect Secure does not support the following JavaScript code:

window.location.port = portNo