CODEWITHSUNDEEP
corswebsphere-liberty
Westy
Westy

Reputation: 727

WebSphere Liberty CORS Feature Problems

I am trying to use the new CORS feature in WebSphere Liberty Profile 8.5.5.9. I think I have it set up correctly, but it is not working at all, so it's possible that I got the configuration wrong. There is nothing in the log one way or the other - no errors or informational messages.

Is there some kind of trace I could turn on that would show me anything about the CORS feature and possibly why it's not working?

Here is our config: 

<cors domain="/TalentPlayBookService/rest" allowedOrigins="https://w3dev.somerslab.ibm.com/"
    allowedMethods="GET, HEAD, POST, PUT"
    allowedHeaders="Referer, Cache-Control, Pragma, Accept, Accept-Language, Accept-Encoding, Accept-Charset, Content-Type, Content-Length, User-Agent, Authorization, passwd, X-Update-Nonce, X-Shindig-ST, X-IC-CRE-Request-Origin, X-IC-CRE-User, X-LConn-Auth, Accept*, Content*"
    exposeHeaders="Content-Type, Last-Modified, etag" 
    allowCredentials="true" maxAge="3600" />

Upvotes: 1

Views: 1277

Answers (2)

ArthurDM
ArthurDM

Reputation: 403

The following trace setting will activate CORS logging:

<logging traceSpecification="CorsService=finest"/>

You should see a "handleRequest" method invocation from CorsRequestInterceptor.

Edit: If you see a trace from "isCorsSupportEnabled" coming back as true, that means your CORS configuration is being picked up. However, if you do not see a trace entry from "logCorsRequestInfo" it means that the client invocation did not specify the required header called "Origin".

I suggest you do a F12 on your browser to see if the outgoing headers/origin, etc, are as expected. Specifically, if the "Origin" header is being passed from the client.

Edit #2 Liberty's CORS interceptor is at the filter-level, so think of it as a filter that applies to all domains (apps) that you configure with the cors element in server.xml. This means that the current CORS support won't handle requests that do not reach the filter layer, such as the 401 you mentioned in your other answer. This is known limitation that is being taken into consideration for future requirements.

Upvotes: 1

Westy
Westy

Reputation: 727

So I think I see what the problem is. On a previous project, on an older version of WLP, we needed to create a CORS filter for the application. However, we were using BasicAuth, and were running into a problem when a 401 was returned, because the response did not have the proper CORS headers. Since our CORS filter was specified at the app level, and WLP itself was sending back the 401, our filter never got fired. So we ended up needing to have an AjaxProxy service in between.

With WLP 8.5.5.9, and the CORS feature, I made the bad assumption that, since the feature is configured at the server level, and not in the app, that it would be able to handle a situation like this, where WLP responds with the 401 if the user is not yet authorized. It appears that is not the case here. It seems that this feature does not handle 401s that don't come from the app itself.

So I guess I overestimated the functionality of the CORS feature.

Upvotes: 0

Related Questions