Layer7 API Management

Does anyone know what would cause one API/Application from API Explorer to send a CORS preflight to the gateway while another does not?  We have two portal published API's, sending both with an API key.  One of them sends two requests that show up in the audit, the first apparently being a preflight that "fails", as you might expect because the "Portal Service Preface" apparently identifies it as "cors.isPreflight".  The second works.  So the test succeeds, it's just odd that we have another API that when tested in the same manner works with a single run.

It's the client -- your browser, to decide when to send the CORS preflight request. 

Different browser may have different implementation. Usually, "simple requests" don't trigger preflight check.

The document below may give your more info,

Cross-Origin Resource Sharing (CORS) - HTTP | MDN 

Regards,

Mark

The browser doesn't change, these are "Try It" type invocations sent back to back from API Explorer in the Portal 4.2.7 interface, running in Chrome.  Neither the app's or the api's used are defined differently.  I even assigned and sent the one doing the preflight with the other's application.  No difference.  The registrations are set up the same way in OAuth.  Everything appears to be similar, cut one send a preflight, the other does not.

Any difference between the requests of  the 2 api ? HTTP method, headers, content-type?

I see how that would matter, but again it's all done by API Explorer and there doesn't seem to be any way to manipulate those attributes from there.  I wonder if possibly the Swagger file has anything to do with it.  That's really the only place it seems you can really adjust things in API Explorer.

Yes, API explorer is based on the swagger, wadl, etc.

If your swagger define a non-simple request, it will trigger preflight check.

I have the exact same issue. "Portal Service Preface" stops processing as preflight = true. How did you solve this? TO me it appears as though I'm going to have to add assertions to every portal deployed API. We define ours with swagger.  

We didn't actually solve it.  What was occurring for us was, the request was sent once with the preflight set true, which would fail, but then it would follow up with a subsequent request that worked (apparently not a preflight).  So the transaction ultimately worked, it was just cluttering up our audit log and not being very efficient in its operation.  It wasn't a serious enough problem to devote time to resolving.  The theory is the Swagger file could control it, but I'm not a swagger expert and I'd have to dig and experiment to know how.

Appreciate the reply, thank you! That might be what I'm seeing actually. An initial failure that I'm confusing with a subsequent error from the backend.. Pretty sure the portal preface should add in some CORS handling. 

The line in swagger that would result in a cross domain call would be the 'host' line which specifies the proxy (the gateway) if the API Explorer Default Proxy is not filled in (Settings/Basic). In my case that's always true as we use SaaS portal and local gateway. 

Pete,

Are you still seeing this issue or did any of the suggestion help?

Sincerely,

Stephen Hughes

Broadcom Support

It was months ago and I honestly don't remember all the details.  As noted earlier, it really wasn't important enough to resolve and seems even less so now, as Portal seems to have died on the vine.  We built it, but nobody came.  Who knows, maybe next week it'll get resurrected, I can never predict, but for now the issue has no importance so I can't spend any more time on it.

Peter,

I appreciate you letting us know where this stood. Not great to hear about the Portal not moving forward at the this time. Take care of yourself and have a great long weekend.

Sincerely,

Stephen Hughes

Broadcom Support

This may be of use:

TechTip : When you need API Gateway Service to respond to both CORS and not CORS requests 

There was very strict definition of what a "simple" request was, in our case adding a header was the cause. 

So then IE (and other browsers) would do the CORS request, but requests from wget and curl would not. 

Note from elsewhere: 

It is not always clear if an OPTIONS request is going to be sent.   But browsers can upgrade a normal GET request to one that makes an OPTIONS request before the GET/POST/PUSH request.  It does this when the request does not fall into the "simple" category.    Cross-origin resource sharing - Wikiwand 

Since we had managed api's we could modify them on the gateway, as above link, to accept both CORS and non CORS requests. 

There was Idea for better support too : 

Better CORS support for API Portal when service pushed to API Gateway 

Cheers - Mark