Archive for the ‘Apache Wicket’ Category

I have been working with wicket for the last one year. It is one of the best web frameworks. In our organization, we are using Oracle Application Sever (OAS) to deploy our applications. We were using OAS and we had no issues with wicket. Recently we upgraded our OAS to and then issues started to appear one after the other.

The first issue that we were facing was with securing the application. We are using Oracle LDAP as our user manager for Authorization and Oracle SSO (Single Sign On) for authentication. The authentication and authorization are working fine if the URL used to access the application is not terminated by a slash “/”. Users are asked to login and only authorized user can access the application. However authentication and authorization are bypassed when the URL used to access the application is terminated with a slash “/”. Users are not even asked to login to the system to access the application.

After debugging and investigating, we noticed that if we use wicket servlet to load our application instead of wicket filter, then the security issue is resolved. However that brought up another issue that is there even in OAS 9.0.4.

The second issue is that, when using wicket servlet, the context which is specified in the servlet mapping in web.xml is omitted by OAS. The same problem was reported in wicket forum [1] and [2]. The context was omitted while sending the response back to the client only and not while sending the request to the server. The reason for this behavior is still ambiguous but we have developed a workaround for the issue. We have implemented a filter that adds the omitted context to the response. Here is our sample filter code

package com.datel.sample.webapplication;

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;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

public class ContextFilter implements Filter{

	private FilterConfig config;

	//Used to store the servlet mapping URL that is defined in the web.xml
	private String servletMappingContext;

	public void destroy() {
		config = null;
		servletMappingContext = null;

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		HttpServletRequest httpRequest = (HttpServletRequest)request;
		HttpServletResponse httpResponse = (HttpServletResponse)response;

		if(servletMappingContext == null || servletMappingContext.length()==0)
			//The getRequestURI returns the full context i.e. /sampleWicket/app/

		myServletResponse newResponse = new myServletResponse(httpResponse);
		chain.doFilter(request, newResponse);

	private void setServletMappingContext(String requestURI) {
		//1. remove last / if it exists
		if (requestURI.endsWith("/"))
			requestURI = requestURI.substring(0, requestURI.length()-1);

		//2. get only the servlet mapping defined in web.xml i.e /app
		requestURI = requestURI.substring(requestURI.lastIndexOf("/"));

		//3. remove the prefixed /
		requestURI = requestURI.substring(1);

		//4. append the / at the end
		servletMappingContext = requestURI+="/";

	public void init(FilterConfig config) throws ServletException {
		this.config = config;

	class myServletResponse extends HttpServletResponseWrapper
		public myServletResponse(HttpServletResponse arg0) {
		public void sendRedirect(String arg0) throws IOException {
			// Add the context to the query string


In the web.xml you need to add the filter:


Please note that this filter will always add the context to the query string and thus it will only work with Application servers that omit the context. It will not work with Tomcat for example. This is because in the response we don’t have handle to the full URL. We have a handle only to the query string.

Due to that we have reported the first issue, Securing Web Applications, to Oracle Support. Oracle was able to reproduce the problem and they agreed to file it as a bug and they suggested to download the latest patchset 5983622 Oracle Fusion Middleware to resolve the problem. We have done so and our application is now secured without the need to go for wicket servlet. We were using Wicket 1.3.4.

[1] http://www.nabble.com/wicket-servlet-mapping-to-subdirectory-td18012945.html#a18012945
[1] http://www.nabble.com/Wicket-cannot-work-on-OC4J-(ias-10g)–td16738242.html#a16744020


Read Full Post »