Problems Resteasy 3.09 Corsfilter

Problems Resteasy 3.09 CorsFilter

"Is there another way to configure this CorsFilter and enable the resource scanning?"

One way to keep the scanning is just to implement a javax.ws.rs.core.Feature

import javax.ws.rs.core.Feature;
import javax.ws.rs.core.FeatureContext;
import javax.ws.rs.ext.Provider;
import org.jboss.resteasy.plugins.interceptors.CorsFilter;

@Provider
public class CorsFeature implements Feature {

    @Override
    public boolean configure(FeatureContext context) {
        CorsFilter corsFilter = new CorsFilter();
        corsFilter.getAllowedOrigins().add("*");
        context.register(corsFilter);
        return true;
    }  
}

This feature will get scanned for just like all other @Providers and @Paths.

Test with only

@ApplicationPath("/api")
public class RestApplication extends Application {
}

C:\>curl -i http://localhost:8080/api/simple -H "Origin:stackoverflow.com"
HTTP/1.1 200 OK
Date: Wed, 01 Apr 2015 12:07:22 GMT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: stackoverflow.com
Content-Type: application/octet-stream
Content-Length: 15
Server: Jetty(9.2.4.v20141103)

Hello Response!

Cannot access services after adding corsfilter in resteasy

A JAX-RS application can be configured with no web.xml and an empty Application subclass with @ApplicationPath. With this class, this is enough for your JAX-RS application to be bootstrapped, and the JAX-RS runtime will scan the classpath for all classes annotated with @Path and @Provider, and automatically register those classes with the application.

@ApplicationPath("/api")
public class JaxRsApplication extends Application {}

Once you override the getSingeletons() or getClasses() and return a non-empty set in either of them, you disable the automatic registration of classes through classpath scanning. Since you have done so, your resources are no longer automatically registered. So now you can do a couple things:

1. Just register the resources class(es) that was before automatically registered

   classes.add(MyResource.class);
   

2. You can have a look at this answer, which uses a Feature annotated with @Provider. The Feature will get registered because of the classpath scanning. In this feature is where you can register the CorsFilter with the FeatureContext.

CORS Response Filter not invoked Resteasy / JAX-RS 2.0

So I've started over from scratch with a new project to eliminate error sources. Thanks for the input on using @Provider and adding OPTIONS. Plus I removed all configuration REST from the web.xml.

@Provider is essential for the Filter to work

ServiceCorsFilter.java

@Provider
public class ServiceCorsFilter implements ContainerResponseFilter {

    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
        responseContext.getHeaders().putSingle("Access-Control-Allow-Origin", "*");
        responseContext.getHeaders().putSingle("Access-Control-Allow-Methods", "OPTIONS, GET, POST, PUT, DELETE");
        responseContext.getHeaders().putSingle("Access-Control-Allow-Headers", "Content-Type");                       
    }    
}

@ApplicationPath makes web.xml configuration obsolete

ServiceConfig.java

    @ApplicationPath("service")
public class ServiceConfig extends Application {

    private Set<Object> singletons = new HashSet<>();

    public ServiceConfig() {
        singletons.add(new UserServiceV1());
        singletons.add(new ServiceCorsFilter());
    }

    @Override
    public Set<Object> getSingletons() {
        return singletons;
    }

}

This is what is left in the web.xml

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <display-name>MyApp</display-name>
    <!-- No REST related config due the the @Provider and inheritance of Application-->
</web-app>

Ajax request with JAX-RS/RESTEasy implementing CORS

The problem you are having is your are trying to do cross-site scripting. You accessed the page at http://MyIP:8080 and so the browser is preventing you from accessing resources outside that domain. This is very browser specific and browser based work arounds will all be different (you can disable security in Chrome globally, and on a per site basis in IE).

If you load the page as http://localhost:8080, it should then allow you access the query. Alternatively, you can implement a proxy which will forward the request.

No 'Access-Control-Allow-Origin' header is present on the requested resource - Resteasy

Your resource methods won't get hit, so their headers will never get set. The reason is that there is what's called a preflight request before the actual request, which is an OPTIONS request. So the error comes from the fact that the preflight request doesn't produce the necessary headers.

For RESTeasy, you should use CorsFilter. You can see here for some example how to configure it. This filter will handle the preflight request. So you can remove all those headers you have in your resource methods.

See Also:

• HTTP access control (CORS)

What is the proper replacement of the Resteasy 3.X PreProcessInterceptor?

RESTEasy 3.x.x conforms to the JAX-RS 2.0 specification.

What you are trying to do could be accomplished (maybe better) with:

@Provider
public class SecurityInterceptor 
      implements javax.ws.rs.container.ContainerRequestFilter {
     @Override
     public void filter(ContainerRequestContext requestContext){
       if (not_authenticated){ requestContext.abortWith(response)};
     }
}

since the ReaderInterceptor is invoked only if the underlying MessageBodyReader.readFrom is called by the standard JAX-RS pipeline, not fromthe application code.

The reason why your interceptor is not called, though, could be the @ServerInterceptor annotation, which is a RESTEasy extension.

The spec states at §6.5.2 that a interceptor is globally registered, unless the @Provider is annotated with a @NameBinding annotation, but I don't know if RESTEasy can handle a @ServerInterceptor if it's not explicitly registered as shown in RestEASY Interceptor Not Being Called

---

Related Topics