{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • Product Announcements
    • General
    • Edge/API Management
    • Developer Portal (Drupal-based)
    • Developer Portal (Integrated)
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Adapter for Envoy
    • Analytics
    • Events
    • Hybrid
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • 日本語コミュニティ
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Edge/API Management /
avatar image
1
Question by acharnley44 · Jan 01, 2015 at 05:28 AM · 2.2k Views cors

Add headers (cors) to 401(etc) invalid token response

The title is probably enough.

Preflight OPTIONS are working but we need to set the cors headers on Apigee's oauth errors. Andrew

Comment
Add comment
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Close

3 Answers

  • Sort: 
avatar image
0

Answer by Michael Malloy   · Jan 02, 2015 at 12:15 AM

You should be able to do this via an Assign Message policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="[Put name here]">
    <DisplayName>[Put display name here]</DisplayName>
    <FaultRules/>
    <Properties/>
     <Set>
            <Headers>
		<Header> [Put CORS header here] </Header>
		<Header> [Any other header] </Header>
	    </Headers>
          <Payload contentType="application/json">\{ "error": "Put error response here"} </Payload>
            <StatusCode>401</StatusCode>
            <ReasonPhrase>[Put Reason Code Here]</ReasonPhrase>
        </Set>
</AssignMessage>

You could follow this by a Raise Fault policy if you want to return immediately.

Be sure to put sufficient <Condition></Condition> clauses in your flow code to handle this situation.

Comment
Add comment Show 4 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Michael Malloy ♦   · Jan 02, 2015 at 12:17 AM 0
Link

Please let me know if that does what you intended it to do. Otherwise, I'll be glad to look into it further.

avatar image Chris Covney Michael Malloy ♦ · Apr 27, 2015 at 05:15 PM 0
Link

Hi Michael,

This does not do it for the Apigee Policy-Generated errors (like when an invalid auth code is passed to the access_token endpoint during the authorization_code flow). When a policy throws an error, Apigee strips all the content from the request thus far and returns only the policy's own error message.

Any idea how to force Apigee to honor the CORS headers previously added via an assign message policy like the one you referenced above?

Thanks!

Chris

Just FYI, this is slightly different than the issue expressed in:http://community.apigee.com/questions/657/oauth2-and-cors.html

because I see my add cors policy is executed, but its content is removed when a policy throws its own error.

avatar image Stuart Ruiz Michael Malloy ♦ · Jun 10, 2020 at 10:01 PM 0
Link

So it seems most of these solutions simply set the CORS headers to "*" allowing any, possibly malicious, user to access them. I see the logic in that these are simply error messages so the concern is lowered, but it feels like a possible security flaw. Any thoughts? And is there an alternative?

avatar image Dino-at-Google ♦♦ Stuart Ruiz   · Jun 15, 2020 at 11:07 PM 0
Link

Correct! Setting the Access-Control-Allow-Origin header to "*" effectively disables CORS. Which eliminates its protections.

The ideal thing is for people to use the appropriate hostname in that field.

Apigee is working on a policy that will provide better, more nuanced CORS support.

Stay tuned.

avatar image
0

Answer by Jovani Arzate · Apr 10, 2019 at 06:32 AM

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

<PreFlow name="PreFlow">
  <Request>
    <Step>
      <Name>FC-CORS</Name>
    </Step>
    <Step>
      <Name>FC-OAuth2</Name>
    </Step>
  </Request>
  <Response/>
</PreFlow>

Definition of flowcallout, where we invoke the sharedflow

<FlowCallout name="FC-CORS">
  <SharedFlowBundle>OPTIONS-CORS-Headers-Response</SharedFlowBundle>
</FlowCallout>

definition of sharedflow

<SharedFlow name="default">
  <Step>
    <Name>OPTIONS-CORS-Headers-Response</Name>
    <Condition>request.verb == "OPTIONS"</Condition>
  </Step>
</SharedFlow>

definition of the policy of raisefault, where we will indicate the headers of Access-Control-Allow-Origin with * that will allow the invocation from our browser:

<RaiseFault  name="OPTIONS-CORS-Headers-Response">
	  <Set>
	  <Headers>
	  <Header name="Access-Control-Allow-Origin">*</Header>
	  <Header name="Access-Control-Allow-Headers">origin, 
x-requested-with, accept, ucsb-api-key, ucsb-api-version, 
authorization</Header>
	  <Header name="Access-Control-Max-Age">3628800</Header>
	  <Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header>
	  </Headers>
	  <Payload contentType="text/plain"/>
	  <StatusCode>200</StatusCode>
	  <ReasonPhrase>OK</ReasonPhrase>
	  </Set>
	  </FaultResponse>
	  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

Regards

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
0

Answer by Joshua Cariño · Sep 18, 2019 at 03:15 AM

We got this working by adding CORS Policy on the RaiseFault Policy erroring out. Like this

<FaultResponse>
        <Set>
            <Headers>
                <Header name="Access-Control-Allow-Origin">*</Header>
                <Header name="Access-Control-Allow-Credentials">true</Header>
                <Header name="Access-Control-Allow-Headers">
                    origin, x-requested-with, accept, content-type, authorization
                </Header>
                <Header name="Access-Control-Max-Age">3628800</Header>
                <Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE, OPTIONS</Header>
            </Headers>
            <StatusCode>404</StatusCode>
            <ReasonPhrase>Not Found</ReasonPhrase>
            <Payload contentType="application/json">
                {
                "Code" : "404" ,
                "Message" : "Invalid or missing resource (path)."
                }
            </Payload>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

Is there a way we could prevent this hardcoding the CORS policies in the Raise Faults and override Apigees default behavior of overriding previously sent CORS Policies?.

Comment
Add comment Show 1 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Dino-at-Google ♦♦   · Jun 15, 2020 at 11:13 PM 0
Link

@marshg@google.com - FYI

I know this is an old question but it's valid and still worth answering.

Today there is no good way to avoid what you are doing.

Apigee is working on a policy to assist with this, so that you don't need to sprinkle CORS stuff in various policies around your proxy. I have no expected time of availability of that policy, but we're working on it.

Follow this Question

Answers Answers and Comments

7 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

Apigee Pre-Flight Options Requests 3 Answers

CORS issue while sending APIKEY as header. 1 Answer

Adding CORS causes deploy error 2 Answers

CORs - Securing My Endpoint to only allow Apigee Edge 3 Answers

CORS preflight issue with apikey verfication failed. 2 Answers

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2021 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • Product Announcements
  • General
  • Edge/API Management
  • Developer Portal (Drupal-based)
  • Developer Portal (Integrated)
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Adapter for Envoy
  • Analytics
  • Events
  • Hybrid
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • 日本語コミュニティ
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Badges