‘Access-Control-Allow-Origin’ missing whenever I add "Verify OAuth v2.0 Access Token"

Google Cloud Apigee
1

I’m trying to allow CORS from my API so that a minimalist test piece of Javascript can play around with sending Google auth tokens. I have “Add CORS” sitting on my TargetEndPoint PreFlow and it appears to work. Access-Control-Allow-Origin comes through as *, I have a OptionPreFlight flow set up on the Proxy Endpoint as detailed here: http://docs.apigee.com/api-services/content/adding-cors-support-api-proxy and all is right with the world.

However, all is only right when I disable the “Verify OAuth v2.0 Access Token” and “Remove Header Authorization” policies that were attached to the Proxy EndPoint PreFlow when I first configured the API Proxy. When they are there I get “CORS header ‘Access-Control-Allow-Origin’ missing” and when they are gone I get straight through to the API that is being proxied.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>verify-oauth-v2-access-token</Name>
            </Step>
            <Step>
                <Name>remove-header-authorization</Name>
            </Step>
        </Request>
        <Response>
        </Response>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows>
        <Flow name="OptionsPreFlight">
            <Request/>
            <Response>
                <Step>
                    <Name>add-cors</Name>
                </Step>
            </Response>
            <Condition>request.verb == "OPTIONS"</Condition>
        </Flow>
    </Flows>
    <HTTPProxyConnection>
        <BasePath>/niwaweather-authed</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="NoRoute">
        <Condition>request.verb == "OPTIONS"</Condition>
    </RouteRule>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response>
            <Step>
                <Name>add-cors</Name>
            </Step>
        </Response>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://weather.niwa.co.nz</URL>
    </HTTPTargetConnection>
</TargetEndpoint>
2

@Craig Stanton I didn’t understand the problem. Maybe its very specific to your implementation. It would be good, if you can attach the sample proxy bundle or the policy configuration here.

Are you saying, when you enable the “Verify OAuth v2.0 Access Token” and “Remove Header Authorization”, the CORS headers are no longer added. If that’s the case, you need to make sure that the policy that adds the CORS headers, gets executed correctly and is able to set the headers in the response.

3

The Add-cors police is working fine, except when I add the Verify OAuth Token. When ever I add that policy the javascript making the call reports that the ‘Access-Control-Allow-Origin’ is missing. If I remove the Verify OAuth Token policy the javascript is able to get to the API and I can see the CORS header is there.

4

@Craig Stanton, As said by @arghya das , We need a way to reproduce above error. Can you attach a sample proxy with mock target & steps to reproduce same OR post your policies xml to better understand same ?

5

I’ve inserted the two endpoints. The three steps (“verify-oauth-v2-access-token” etc) are standard, I’ve done no extra config.

6 
hey guys, I implemented something like that and it served me correctly.


In the proxy enpoint we must place in the preflow the next call of a Flowcallout to invoke a sharedflow which will have the policy of CORS
FC-CORS FC-OAuth2 
Definition of flowcallout, where we invoke the sharedflow
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> FC-CORS OPTIONS-CORS-Headers-Response 
definition of sharedflow
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> OPTIONS-CORS-Headers-Response request.verb == "OPTIONS" 
definition of the policy of raisefull, where we will indicate the headers of Access-Control-Allow-Origin with * that will allow the invocation from our browser
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> OPTIONS CORS Headers Response * origin, x-requested-with, accept, ucsb-api-key, ucsb-api-version, authorization 3628800 GET, PUT, POST, DELETE 200 OK true

angular:

const httpOptions2= { headers:newHttpHeaders({ ‘Authorization’:‘Bearer token’ }) };

obtenerCatalogos():Observable { return this.httpClient.get(uriApigee+‘endpointapigee’,httpOptions2); }

Regars

7

Many years later I hit and solved a very similar problem

8

Posting an answer to send en email to myself to find out which account it thinks this is and why it thinks I am not it.