<div dir="ltr"><div>Had to create a new version of my API and re-publish, but it worked. <br><br></div>Thank you.<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 22, 2016 at 10:59 AM Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure thing! The problem is that the web.xml file in the<br>
apiman-gateway-api.war web application is too restrictive. This is what<br>
I mean:<br>
<br>
<a href="https://github.com/apiman/apiman/blob/master/gateway/platforms/war/wildfly8/api/src/main/webapp/WEB-INF/web.xml#L40-L48" rel="noreferrer" target="_blank">https://github.com/apiman/apiman/blob/master/gateway/platforms/war/wildfly8/api/src/main/webapp/WEB-INF/web.xml#L40-L48</a><br>
<br>
That security constraint is too restrictive. The<br>
<web-resource-collection> should specify which http methods to secure.<br>
Because it doesn't do this, *all* of the http methods are secured by<br>
default. Here is an example that does it correctly with respect to CORS:<br>
<br>
<a href="https://github.com/apiman/apiman/blob/master/manager/api/war/wildfly8/src/main/webapp/WEB-INF/web.xml#L74-L82" rel="noreferrer" target="_blank">https://github.com/apiman/apiman/blob/master/manager/api/war/wildfly8/src/main/webapp/WEB-INF/web.xml#L74-L82</a><br>
<br>
So here's what you need to do:<br>
<br>
1) unpack WILDFLY/standalone/deployments/apiman-gateway-api.war<br>
2) open the WEB-INF/web.xml file in a text editor<br>
3) add the following XML markup after line 43:<br>
<br>
<http-method>GET</http-method><br>
<http-method>POST</http-method><br>
<http-method>PUT</http-method><br>
<http-method>DELETE</http-method><br>
<http-method>HEAD</http-method><br>
<br>
4) save the web.xml changes<br>
5) re-zip everything, resulting in a new version of<br>
apiman-gateway-api.war<br>
6) deploy the new version of apiman-gateway-api.war to Wildfly,<br>
replacing the old version<br>
7) start wildfly<br>
8) profit!<br>
<br>
-Eric<br>
<br>
On 7/22/2016 8:23 AM, Jairo Junior wrote:<br>
> I would like the workaround. =)<br>
><br>
> On Fri, Jul 22, 2016 at 9:15 AM Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a><br>
> <mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>> wrote:<br>
><br>
> Thanks for the info. You've hit a bug in apiman, unfortunately. I have<br>
> created a ticket for this bug here:<br>
><br>
> <a href="https://issues.jboss.org/browse/APIMAN-1209" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/APIMAN-1209</a><br>
><br>
> You can resolve (workaround) this issue locally (without rebuilding<br>
> apiman) or you can wait for us to fix the bug and release a new version.<br>
> If you would like instructions on how to workaround the bug locally<br>
> let me know.<br>
><br>
> -Eric<br>
><br>
> On 7/22/2016 7:55 AM, Jairo Junior wrote:<br>
> > EAP 7.0 + apiman 1.2.7 overlay, but I've also tried with docker image<br>
> > apiman/on-wildfly10:1.2.7.Final<br>
> ><br>
> > /apiman-gateway/org/service/1.0 with Keycloak OAuth Policy<br>
> ><br>
> > On Fri, Jul 22, 2016 at 8:29 AM Eric Wittmann<br>
> <<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a> <mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>><br>
> > <mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a><br>
> <mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>>> wrote:<br>
> ><br>
> > Apiman should allow OPTIONS requests without requiring<br>
> authorization.<br>
> > What is your setup/configuration (which app server, etc)?<br>
> Also what<br>
> > apiman REST endpoints are you trying to access?<br>
> ><br>
> > -Eric<br>
> ><br>
> > On 7/22/2016 7:22 AM, Jairo Junior wrote:<br>
> > > I've been trying to setup apiman + keycloak-oauth-plugin +<br>
> keycloak +<br>
> > > keycloak.js with a client-side angularjs app and a REST API.<br>
> It's a<br>
> > > scenario very similar to<br>
> > ><br>
> ><br>
> <a href="https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app" rel="noreferrer" target="_blank">https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app</a>,<br>
> > > but with apiman and CORS.<br>
> > ><br>
> > > My test are going well with curl, but using my javascript<br>
> app the<br>
> > > browser it is performing a CORS preflight OPTIONS request<br>
> without<br>
> > > authorization header.<br>
> > ><br>
> > > OPTIONS request works well with authorization header using curl,<br>
> > > therefore, I'm not sure whether the browser should include<br>
> > authorization<br>
> > > header or apiman should allows CORS preflight requests (OPTIONS)<br>
> > without<br>
> > > authorization header.<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > Apiman-user mailing list<br>
> > > <a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a>><br>
> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a>>><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/apiman-user</a><br>
> > ><br>
> ><br>
><br>
</blockquote></div>