Edge microgateway CORS plugin

[#1]

We have added the cors plugin to our edge microgateway but internal sites are still disallowed and the edge portal "Try it out" function fails. We are using the PCF service broker binding to route from our app to edge micro. Has anyone had experience with this? The OPTIONS call seems correct but the GET does not have the needed access control header. Is there something else in the code that is overwriting the headers?

[Former Community Member · Accepted solution]

I believe the latest version of Microgateway fixes that problem. What version of MG are you using?

[#3]

@srinandans Currently using microgateway 2.5.7. I will try 2.5.19 to see if that works.

[#4]

@srinandans- I deployed 2.5.19. We are still getting the same result. No 'Access-Control-Allow-Origin' header is present on the requested resource.

[marutichandc]

@chblackwell, As you are using the PCF MGW plan, can you see at the GoRouter if the header is present at that point or not? this can help us isolate which compoenent/layer is dropping the header.
As these calls are originated from the portal using smart docs, the calls are not routed directly to the PCF layer but through a smartdocs proxy.

[#6]

This is the Edge portal, not the Drupal portal. It looks like the Edge portal makes a direct call to the PCF route. If the Edge portal called a backend proxy it is unlikely there would be a CORS issue.

[Former Community Member]

Here is the code: https://github.com/apigee/microgateway-plugins/blob/master/cors/index.js#L26

The access-control-allow-origin header is being set.

[#8]

There is still a bug in the cors plugin. If no 'origin' header exists the microgateway responds with a "no value set" error. Only browser requests add the origin header; service to service calls and postman calls don't add it. I fixed our version of the plugin but Apigee should fix the distributed version.

[dchiesa1]

Hi @chblackwell -

1. Can you describe more precisely the problem or bug you are seeing and fixing? You said "only browser requests add the header". what does that mean? Are you saying only requests made from a browser include a specific header? if so, which header? Are you saying instead that only when a browser makes the request, does the EMG respond with a "Access-Control-Allow-Origin" header? if so, is that a problem? CORS is a browser-enforced mechanism, so if EMG doesn't send a CORS header back to a "service" , then... (shrug) there should be no effect at all. I probably am misunderstanding something.

2. did you file a PR against the microgateway-plugins repo with your fix? Can you link it here?

[shapandashore-1]

@Dino-at-Google adn @Kurt Googler Kanaskie, I'm currently on an issue where we are getting "502 bad gateway error: Registered endpoint failed to handle the request". After tailing logs in PCF on the edge-micro app we saw the following error:

error m=OPTIONS, u=/cloudfoundryapplication, h=edgemicro-dev.apps.pcf.company.com, r=10.255.170.53:37200, s=404, name=Error, message=no match found for /cloudfoundryapplication, code=undefined, stack=Error: no match found for /cloudfoundryapplication

we also tried enabling the cors plugin, but we are seeing the same issue.
We have a .NET app which is using the steeltoe-config (https://steeltoe.io/docs/steeltoe-configuration/) to make the options call to get config details.
Has anyone seen this issue before?