Layer 7 API Management

Expand all | Collapse all

CORS PreFlight from API Explorer

  • 1.  CORS PreFlight from API Explorer

    Posted 07-13-2018 03:59 PM

    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.



  • 2.  Re: CORS PreFlight from API Explorer

    Posted 07-16-2018 03:37 AM

    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



  • 3.  Re: CORS PreFlight from API Explorer

    Posted 07-16-2018 10:13 AM

    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.



  • 4.  Re: CORS PreFlight from API Explorer

    Posted 07-16-2018 08:44 PM

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



  • 5.  Re: CORS PreFlight from API Explorer

    Posted 07-17-2018 11:29 AM

    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.



  • 6.  Re: CORS PreFlight from API Explorer

    Posted 07-18-2018 02:23 AM

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

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



  • 7.  Re: CORS PreFlight from API Explorer

    Posted 07-30-2018 12:03 PM

    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.  



  • 8.  Re: CORS PreFlight from API Explorer

    Posted 07-30-2018 02:17 PM

    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.



  • 9.  Re: CORS PreFlight from API Explorer

    Posted 07-30-2018 02:30 PM

    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 



  • 10.  Re: CORS PreFlight from API Explorer

    Posted 08-02-2018 08:21 PM

    Hi Pete,

     

    I hope you're doing well these days, long time no talk.

     

    I'm not sure if this is exactly what is at play in your particular environment, but I know we've had some CORS-related issues in Portal 4.2.x earlier which were later corrected. The documentation lists two specific scenarios but my understanding is others were resolved as a matter of those two being resolved. Reference of the CORS-related fixes for 4.2.7.1: https://docops.ca.com/ca-api-developer-portal-enhanced-experience/4-2/en/release-notes-api-developer-portal/resolved-issues#ResolvedIssues-ResolvedIssuesinRelease4.2.7.1

     

    As a result, I'd suggest upgrading to at least 4.2.7.1 or higher, and see if the behaviour for you is the same. If it is, then we can likely assume it's back to being something to do with the browser client or Swagger file.



  • 11.  Re: CORS PreFlight from API Explorer

    Posted 02-14-2019 06:20 PM

    Pete,

     

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

     

    Sincerely,

     

    Stephen Hughes

    Broadcom Support



  • 12.  Re: CORS PreFlight from API Explorer

    Posted 02-15-2019 10:43 AM

    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.



  • 13.  Re: CORS PreFlight from API Explorer

    Posted 02-15-2019 12:58 PM

    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



  • 14.  Re: CORS PreFlight from API Explorer

    Posted 02-14-2019 06:40 PM

    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