Question

In our web.xml we have something like

 <security-constraint>
    <auth-constraint>
        <role-name>ROLE_USER</role-name>
    </auth-constraint>
    <web-resource-collection>
        <url-pattern>/app/*</url-pattern>
    </web-resource-collection>
</security-constraint>

This is only there for our production Websphere environment.
Now we don’t test with Websphere, we use Jetty and JBoss. So we have specific Spring profiles to deal with the different security configuration for these environment. But Spring profiles scope don’t reach the web.xml and we are stuck with these security-constraint instructions which conflict with Spring Security for our test environments.

Now we could use Maven profiles to deal with that as explained in this question, but that would involve having more than 1 build, and we want to avoid that extremity.

To summarize, is there a way to not take into account the web.xml security for Jetty? (and if you have the answer for JBoss 7, that’d be great too!)

EDIT: error when executing Jetty 6 is http 500 with the short message "No Realm". Another solution could be to log automatically a default dummy user, but I don’t know if this is possible.

Answer 1

The way finally did it (Jetty 6):

we added a jetty-web.xml in WEB-INF:

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="securityHandler">
      <New class="mypackage.util.JettySecurityHandler" />
  </Set>
</Configure>

The overridden SecurityHandler:

package mypackage.util;

import org.mortbay.jetty.Request;
import org.mortbay.jetty.Response;
import org.mortbay.jetty.security.SecurityHandler;
import java.io.IOException;

public class JettySecurityHandler extends SecurityHandler {

    @Override
    public boolean checkSecurityConstraints(String pathInContext, Request request, Response response)
            throws IOException {
        return true;
    }
}

This is not great because:
– custom code
– version specific (won’t work for Jetty 7 and 8)
but it works.