WebGate and the IE / CSS Flicker Bug

Gettng quite specific here - but if you have this problem, you'll appreciate the info...
There is an annoying behavior that can occur in Internet Explorer. It is referred to as the 'IE CSS Flicker Bug'. This bug manifests as repeated requests being issued for the exact same resource (like a gif image). The result is a very slow or, sometimes, unusably slow user interface as the browser bogs down under (sometimes hundreds) of identical requests. For whatever reason, the IE fails to inspect its own cache for image resources that are defined in a CSS declaration and always issues a new request for each instance of the same resource.
Of course, there is a resolution to the issue. This involves tuning some specific settings on the webserver that serves image files.

IIS Webserver Configuration to Correct IE Flicker

The trick is to specifically set some content expiration and cache control headers that trigger IE to look into its own cache before issuing a new request.
On the directory that contains the resources in question configure: (the following is IIS specific but you can extend the same concept to Apache, etc.)

• Enable Content Expiration
• Expire after 30 days
• Cache-Control: max-age=2592000;

! note: there is a typo in the screen shot where the dash character is missing from CacheControl. Should read Cache-Control.

Where the WebGate Fits In

That's all the info you can find about this issue on the web. But if the UI in question is protected by a WebGate, you might apply the above mentioned measures only to find no improvement in the browser behavior. By default, the COREid WebGate is configured to apply two HTTP headers to each response it handles. Out of the box, the value for both CachePragmaHeader and CacheControlHeader is no-cache. Because the WebGate is always the last component to apply headers, it effectively overrides the headers supplied by the web server.
In the WebGateStatic.lst file, change both the CachePragmaHeader and CacheControlHeader to 'public'. (Yes, this may have other consequences so test carefully.)

That should be all that is needed to end any issues with the IE CSS Flicker bug if it, one day, plagues you.

Simplifying COREid Identity System Menus

A common request for COREid customization is removing unused menu options in the User Manager, Group Manager, and Org. Manager applications (like Create User Identity, Deactivated User Identities, Configuration, etc). Some of these customization tasks can be achieved by defining custom user types in obnavigation.xml, avoiding the need for XSL customization.

Unwanted menu options can be removed from a user type or multiple user types can be defined. Choosing one of these defined user types can be done in the following manners (in order of increasing weight):

1. Set the default userType in obnavigation.xml


2. Define an action to pass an attribute or value from the Access System containing the name of the user type as a header variable (named HTTP_OBLIX_USER_TYPE by default)


3. Add a userType=[name] query string parameter to any URL within the User Manager, Group Manager, or Org. Manager

Note: userTypes are different from Styles in COREid, and customizations to each will function independently from the other.

HeaderVar Not Showing Up Or Wrong Value

Have you ever had some header variables show up and not others? You think to yourself, " I must have a different authorization rules or expression that is being invoked and returning different headers." But when you go check in the Access Tester it is the rule that you are thinking of that is being tripped and there are no different actions on the authorization expression.

This is a peculiar problem that sometimes occurs and as near as I can tell this is what causes the problem. Why this seems to be the case, I have no idea. The problem occurs when one header variable name is competely encompassed in anothers name. For example the variable MYNAME is fully encompassed by MYNAMEPREFIX. If MYNAME comes first (or is it the other way around?) in the header variable list then strange things will happen and the results viewable in the header will not be what you expect .

There seem to be two resultions to this: (1) ensure the longer one shows up in the list first OR (2) given them completely disimilar names. I personally think that option 2 is the way to go. Option 1 can be fraught with more heartache if the orders get reversed down the road in a different environment.

I have only witnissed this behaviour on COREid 7 WebGate for IIS 5/6 . It has been repordoced accross separate installations. I have not tried to reproduce it elsewhere yet.