OraTransplant

Single Sign On prevents Caching

Recently we found out that Oracle Single Sign On is preventing caching of all files served from a SSO protected resource. This caused performance issues since all supporting files like GIF images and JavaScripts were not cached in the client browser.

We use Oracle Single Sign On (SSO) to limit access to our web applications. For this we setup Security Constraints in the web.xml of our J2EE applications. On top of that, we also limit access to the entire virtual directory with a Location directive in the Apache config:

  OssoConfigFile /somewhere/osso-https.conf
  OssoIpCheck off
  OssoIdleTimeout off
  
    require valid-user
    AuthType Basic
  

This Location directory makes sure you need a valid SSO session before you are allowed to access anything in this virtual directory. This not only helps protecting resources that the developer “forgot” to protect in the web.xml, but the main reason for this was a workaround for a SSO bug we encountered earlier this year.

But recently we investigated some performance issues with our web applications. As it turns out each page request also reloaded all supporting files like images, javascripts, etc. Somehow the browser did not cache these files in the local browser cache. HTTP Header tracing revealed that headers were sent with the HTTP Response that forbid the client to cache this information:

Pragma: no-cache
Cache-Control: no-store, Public
Expires: Thu, 01 Jan 1970 12:00:00 GMT

Further investigation revealed this was caused by Oracle Single Sign On. The Web Cache Administrator’s Guide shines some light on this. It states that by default mod_osso (single sign on) adds a Surrogate-Control:no-store header to the response. This instructs Web Cache not to cache this page. Testing revealed that mod_osso not only adds this Surrogate-Control header to instruct Oracle Web Cache, but it also adds the headers to instruct the client not to cache these pages (Pragma, Cache-Control and Expires).

The Web Cache Administrator’s Guide also explains how to disable this mod_osso behaviour with the OssoSendCacheHeaders directive in your Apache config. The example in the guide uses it in a Location directive, but testing revealed you can also use it with a Files directive. We used this to exempt certain non-confidential files from the no-proxy regime:

  OssoSendCacheHeaders off

This allows us to still restrict access to all files requiring a valid SSO session, but allows the client to cache some non-confidential files in a local cache for performance reasons. Strangely enough I could not find any reference to the OssoSendCacheHeaders directive in the Single Sign-On Administrator’s Guide.

Forcing a locale with a Servlet Filter and Servlet Request Wrapper

We’re currently developing a couple of new web applications with Oracle JDeveloper 10.1.3.0 using ADF Faces and Business Components. We keep running into problems with the Locale of the application. By default it tries to adhear to the preferred language set in the client browser. Since we’re a European organization working for multiple European countries, this can result in a number of language.

But since we are an international organization that exchanges data between countries, we agreed that all applications and data have to be in English. So, we want to overrule the preferred language as set in the client browser. In ADF Faces it appears you can do this easily in the faces-config.xml:

    
      en
      en
    

This states that English is the only supported locale and also the default one. Unfortunately this does not seem to work all to well in JDeveloper 10.1.3.0. It appears that Business Components is still picking up the preferred language from the client browser. In Business Components we set a format mask on the attribute (e.g. ##0.00). When the browser is set to German or Dutch the numbers with decimals the field is initially displayed with a comma as a decimal separator. When submitting this value with a comma separator an English error message is displayed that the input does not match the specified pattern. When submitting a value with a period as decimal separator the decimals are completely removed (1.75 becomes 1). Committing a value that’s too large to fit in the database column raises a German JBO-26041 error.

It has to be noted the exact same configuration in JDeveloper 10.1.3.1 works fine. The initial value is displayed with a period as decimal separator. Submitting a value with a period as separator works fine and submitting a value with a comma is rejected for not matching the pattern. Committing a too large value to the database raises a English error.

We’re very close to a release, so upgrading to JDeveloper 10.1.3.1 is not an option. So I wanted another way to force the Local to be set to English-US. I ended up writing a Servlet Filter and a Servlet Request Wrapper to overrule the Accept-Language HTTP header as sent by the browser. With the filter and wrapper I can pretend as if the client sends a “Accept-Language: en” header

First comes the HttpServletRequestWrapper that wraps the client HTTP request:

package nl.eurotransplant.decimal.view.locale;

import java.util.Enumeration;
import java.util.Locale;
import java.util.Vector;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

public class LocaleRequestWrapper
        extends HttpServletRequestWrapper {
    public LocaleRequestWrapper(HttpServletRequest req) {
        super(req);
    }

    public Enumeration getLocales() {
        Vector v = new Vector(1);
        v.add(getLocale());
        return v.elements();
    }

    public Locale getLocale() {
        return new Locale("en", "us");
    }
}

Next is the Servlet Filter to install the HTTP Request Wrapper:

package nl.eurotransplant.decimal.view.locale;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

public class LocaleServletFilter implements Filter {
    private FilterConfig _filterConfig = null;

    public void init(FilterConfig filterConfig)
        throws ServletException {
        _filterConfig = filterConfig;
    }

    public void destroy() {
        _filterConfig = null;
    }

    public void doFilter(ServletRequest request,
                         ServletResponse response,
                         FilterChain chain)
        throws IOException, ServletException {
        if (request instanceof HttpServletRequest) {
            HttpServletRequest req = (HttpServletRequest)request;
            LocaleRequestWrapper wrapper =
                new LocaleRequestWrapper(req);
            chain.doFilter(wrapper, response);
        } else {
            chain.doFilter(request, response);
        }

    }
}

When creating a Servlet Filter, JDeveloper probably already installed the servlet filter in the web.xml. You have to specify a URL pattern to match for this filter. Set this to ‘*’ to match all requests. By default the filter-mapping is appended as last in the web.xml. This means this filter is triggered after the ADF filter, which is too late. So you have to edit the web.xml directly to put the filter-mapping for the servlet filter on top:

    
        LocaleServletFilter
        nl.eurotransplant.decimal.view.locale.LocaleServletFilter
    
    
        LocaleServletFilter
        *
    
    
        adfBindings
        *.jsp
    
    
        adfBindings
        *.jspx
    
    
        adfFaces
        *.jsp
    
    
        adfFaces
        *.jspx
    

Run your application and see how it picks up the English language, whatever your preferred language in the client browser is. For us, this is a good solution for the problem we have in 10.1.3.0. In version 10.1.3.1 you can seem to get the same effect with only allowing English in the faces-config.xml:

  
    
      en
      en
    
  

There’s no need to install the servlet filter and http request wrapper in 10.1.3.1