More updates on my adventures with CORS.
I have not tried an InInterceptor yet.
Using the Filtering method
1) If I call chain.dofilter(...) and also add a @Options annotation
on each service then the call hits the CXF servlet but the query param
and form params are empty, which is as expected. So if we go with
this route, defensive programming is required. But on a 200 return,
the header are set properly. (this is at least reasonably workable)
Without an @Options on the service, we get a 404. Not good.
2) If I don't call chain.doFilter(...) the headers disappear. Not
really sure why. But we don't need to defensively program, as the
filter does not continue to the CXFServlet.
Using the annotation method (@Options @Path("/user"))
1) the main problem here is any path parameters. For example,
@Path("/user/{id}") as the endpoint will not be able to match the
above path. This is a little annoying, as I'll need @Paths for all
the possible permutations. Is there a way to do @Path("/user/*") or
something?
So far, none of the methods I've tried are working out very well,
although the filtering thing at least returned a valid CORS response
to the pre-flight call. Next steps, probably explore the
InInterceptor idea.
Jeff
On Mon, Sep 12, 2011 at 2:43 AM, Sergey Beryozkin <[email protected]> wrote:
> Hi Jeff
>
> On 12/09/11 08:33, Jeff Wang wrote:
>>
>> (different contract, same CXF...)
>>
>> Ok, I've got a simple REST Endpoint
>>
>>
>> @Path("/foo")
>> @Post
>> @Consumes("multipart/form-data")
>> public Object registerFoo(@FormParam String name);
>>
>> Now the issue that I have is that the people calling it are actually
>> calling
>> the endpoint from a mobile phone app via an AJAX call. This means that
>> CORS
>> is going to come in play. In other words, I'm going to get a preflight
>> request. (For more information, the good folks at Mozilla has a nice
>> description. https://developer.mozilla.org/En/HTTP_access_control)
>>
>> This means, I will get a
>>
>> OPTIONS /foo
>> Origin: http://mobile.example
>> Access-Control-Request-Method: POST
>> Access-Control-Request-Headers: X-BAR-HEADER
>>
>> which will expect something to the effect of:
>>
>> HTTP/1.1 200 OK
>> Access-Control-Allow-Origin: http://mobile.example
>> Access-Control-Allow-Methods: POST, GET, OPTIONS
>> Access-Control-Allow-Headers: X-BAR-HEADER
>> Access-Control-Max-Age: 1728000
>>
>> before the actual POST will happen. Have anyone implemented cross origin
>> resource sharing on CXF? I see 3 ways of doing this.
>>
>> 1) add @Options on to the endpoint. (or create an endpoint with
>> @Path("/foo") @Options) and return the appropriate headers. the drawback
>> is
>> that I have to do this for each Endpoint.
>
> if all the endpoints can be accessed at "/foo", then may be you can
> introduce an abstract class which will only implement @Options...
>
>> 2) add a filter that works on CXFServlet, and in the doFilter, check it's
>> an
>> Options call, and then based upon the endpoint, set the appropriate
>> header.
>> The problem is that the call should not actually reach CXFServlet, because
>> the OPTIONS method isn't anywhere, so CXF will (eventually) return a 404.
>> Whereas I should just set the return headers, and terminate the filter
>> chain.
>> 3) the same as 2, but use an CXF InInterceptor instead of a filter.
>>
>> I've been working on method 2, because there's already someone that wrote
>> a
>> filter (http://software.dzhuvinov.com/cors-filter.html). I have had
>> difficulties in getting it to work though. I could see the headers
>> getting
>> set, but when I return from the doFilter (instead of calling
>> chain.doFilter(request, response), all I get is a 200 OK but none of the
>> extra headers. Letting the call keep on going to CXF (by calling
>> chain.doFilter) results in a 404. So that's not a good thing either.
>>
> May be that filter is not dealing with HTTPServletResponse correctly, and
> thus the headers are dropped.
> Using CXF JAX-RS filter should work OK - they are allowed to run even if no
> matching resource operation has been found
>
> Cheers, Sergey
>
>> Any pointers on approahces would be much appreciated.
>>
>> Jeff Wang
>>
>
>
