On 8/21/2015 10:17 AM, Eric Wittmann wrote:
Well, I was going to wait on this until I've done some more
testing and
really come up to speed. But can have a go at it now with what I know.
After looking into it, we are in fact *not* using the KC CORS support.
Why are we not using it? That's a great question with a real answer...
but it's what I need more time to figure out. Perhaps @msavy has some
insight into that.
In any case, we've implemented our own CORS support for our API (as a
simple filter). However, as you can imagine it doesn't work for
preflighting because KC denies the OPTIONS request since it doesn't
include the auth creds (the browser doesn't send auth creds for
preflight requests).
So I guess we either need to use the KC CORS support, in which case I
need to figure out why we *stopped* using it. Or else we'd need to
request a way to bypass KC auth for OPTIONS requests.
Ok, this makes a lot more sense now. You disabled our CORS support and
are trying to handle CORS yourself.
What I think you can do is modify your security constraints in web.xml
to allow OPTIONS requests through.
<security-constraint>
<web-resource-collection>
<web-resource-name>wholesale</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
...
</security-constraint>
The above should trigger Keycloak authentication for only GET and POST
methods and let OPTIONS through.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com