ODataV2 and CORS

[Ronny Bremer <rb...@almanid.com>]

Thanks to Michael i got my first OData service up and running. I deployed it to a WildFly 9.0.1 server (the newest release of JBoss).

Our OData consumer is based on Kendo UI, which uses JQuery javascript library to handle the OData connection.

This client piece is deployed on an Apache web server. In order for the client to access the OData web service, I need to set the CORS http header:
“Access-Control-Allow-Origin” and relatives, so that the browser doesn’t complain about not-allowed access.
Reason: even if the apache and the jboss are running on the same server, one uses port 80 and the other 8080, hence it is per se a cross domain access.

I could fix that for all my “getEntity” or “getEntitySet” by adding the appropriate http-headers to the ODataResponse object. However, some browsers seem to perform an OPTIONS http request before accessing the web service, to determine the allowed access headers. A quote from a blog on this topic:

"Finally, for certain types of requests, including BOSH connection manager requests, the permissions check will be pre-flighted. The browser will do an OPTIONS request and expect to get back some HTTP headers that indicate which origins are allowed, which methods are allowed, and how long this authorization will last….”
http://metajack.im/2010/01/19/crossdomain-ajax-for-xmpp-http-binding-made-easy/

Now the OData V2 Servlet will immediately return a NotImplementedError to the caller on OPTIONS requests, building its own ODataResponse and sending it out to the HttpResponse stream. It looks like I cannot intercept that call, so my only solution is to extend the ODataServlet class. Which I can’t because most methods are private.

Is there any “correct” way to insert custom HTTP headers into OData v2 data streams on the server side?

As a workaround I am currently duplicating ODataServlet and add the necessary http headers to the OPTIONS error.

Thank you,

Ronny

Re: ODataV2 and CORS

[Ronny Bremer <rb...@almanid.com>]

And as a small follow up, the OPTIONS call shall not return a 501 not implemented error, cause JQuery will abort its data fetch at that point. So I had to implement a standard response for OPTIONS calls like this:

<code>
ODataResponse odataResponse = ODataResponse.status(HttpStatusCodes.OK)
          .header(HttpHeaders.ALLOW, “GET,POST,OPTIONS,PUT,DELETE,PATCH,MERGE")
          .build();
      createResponse(resp, odataResponse);
</code>

In crreateResponse I added:

resp.setHeader(“Access-Control-Allow-Headers”, “origin, content-type, accept, authorization");
resp.setHeader(“Access-Control-Allow-Origin”, “*”); // which of course is just for demonstration purpose, in a production implementation you need to list the server/port combinations here (basically the referral URL)

Yours,

Ronny