When a protected resource on an Access Gateway includes pages with multiple frames, the page displays incorrectly under the following conditions:
The user’s session times out, the user is redirected to the login page, and the user successfully reauthenticates.
The user logs out, and the logout page redirects the user to a page with multiple frames.
Under these conditions, only the top frame of the page is displayed. To correct this problem:
Create a custom login page for the protected resource.
This can be as simple as creating a copy of the nipd.jsp file and renaming it. For more information on customizing the login page, see Customizing the Identity Server Login Page
in the Novell Access Manager 3.1 SP2 Identity Server Guide.
Copy the custom login page to the JSP directory of the Identity Server.
Linux: /var/opt/novell/tomcat5/webapps/nidp/jsp
Windows: C:\Program Files\Novell\Tomcat\webapps\nidp\jsp
Modify the top.jsp file in the JSP directory.
Locate the following lines in the top.jsp file:
<!-- top.location.href='<%=url%>'; -->
Replace these lines with the following:
<!-- location.href='<%=url%>'; -->
(Conditional) If the Identity Server belongs to a cluster, copy the modified top.jsp file and the custom login page to each Identity Server in the cluster.
Add two property values to the method that creates the contract for the protected resource.
If multiple protected resources are using the contract, you can create a custom method and contract rather than modifying the existing method. For information on this process, see Configuring Authentication Methods
and Configuring Authentication Contracts
in the Novell Access Manager 3.1 SP2 Identity Server Guide.
In the Administration Console, click
.Click the name of the method that is used by the contract for the protected resource.
In the Properties section, click
then specify the following values:Property Name: MainJSP
Property Value: true
Click
.In the Properties section, click
then specify the following values:Property Name: JSP
Property Value: <custom_login_page>
Replace <custom_login_page> with the name of your page, without the JSP extension. (see Step 1). Property values are case sensitive.
Click
twice.Click
, then update the Identity Server.Click
, then update the Access Gateway.(Conditional) If you created a new contract for the protected resource, assign the new contract to the protected resource, then update the Access Gateway.
To verify that the modifications have solved the problem:
Access the page and log in.
Wait for the session to time out.
Access the page again.
Authenticate as prompted and make sure that all the frames are displayed.
HTTP 1.1 has the ability to deal with compressed data in either a Deflate or GZIP format. This reduces the size of data being sent across the wire. Because HTML pages are just text, they typically compress very well.
To use GZIP, you enable your Web servers to send GZIP-compressed data. Be aware that some Web servers do not respond with compressed (GZIP) data when the Access Gateway sends the Via header to the Web server. Check your Web server documentation.
When the Web server sends compressed data and the rewriter needs to process the data, the data is decompressed, rewritten, and then recompressed. When Form Fill needs to process the data, the data is decompressed and then processed. If the Access Gateway does not need to perform any rewriting of the data or if Form Fill does not need to process the data, the compressed data is sent unchanged from the Web server to the browser. This is the default behavior.
To turn off the GZIP feature:
Create the following touch file
touch /var/novell/.noGzipSupport
Restart the Access Gateway.
In the presence of this touch file, Access Gateway does not forward the ACCEPT-ENCODING header to the Web server. Without this header, the Web server does not send any data with GZIP or Deflate encoding to the Access Gateway.
To allow the Access Gateway to receive GZIP or Deflate encoded data, remove the touch file and restart the Access Gateway.
If your protected resources contain references to policies that do not exist, use the following procedure to remove them.
Click
> .In the
section, click .This removes the link between the protected resource and the policy.
Verify that the correct policies are enabled on the protected resources. Click
> > > > > .Change to the
.(Optional) Click the
link to modify existing assignments.Click
, then click the link.Click
> .If you modify the configuration for a protected resource by modifying its
or its Authorization, Identity Injection, or Form Fill policies, save these changes and apply them by clicking , then return to the resource and the changes have not been applied, the protected resource has a corrupted configuration.To repair the configuration:
In the Administration Console, click
> .In the
list, select the resource with the problem, then click .This repairs the configuration for the selected protected resource.
Reconfigure the protected resource with the changes that weren’t applied.
Image display problems can arise when an unprotected page references multiple protected resources. The best practices for HTML is to avoid situations where an unprotected page contains references to multiple, automatically loaded protected resources. For example, the unprotected page index.html might contain references to two GIF image files. Both GIF files are protected resources. The browser automatically attempts to load the GIF files during the initial load of index.html. Because of multiple requests happening at the same time, one or more of the GIFs might be denied access. To avoid this, you should add the index.html page as a protected resource. Doing this avoids the possibility of missing GIFs.
If you see a login page instead of content when you attempt to view mail from an Outlook Web Access server that is protected by the Access Gateway, you need to configure /exchweb/* as a public resource.
With some versions of Internet Explorer 7, if the Access Gateway redirects the first request after authentication to a secure site and if the certificates are not present in the browser, the browser is not redirected to the proper site.
To work around this problem, use the /var/novell/.useJSFor302withIE7 touch file.
When this touch file is used, a 200 OK response is returned with the redirect metatag instead of a 302 redirect.