{ 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
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Developer Portal (Integrated) /
avatar image
0
Question by hyun jeon · Jul 13, 2020 at 01:09 PM · 160 Views portalapikeyldapdevportal dev-portal

Development Portal Try this API - Receiving {"isTrusted": true}

I just finished the tutorials

https://docs.apigee.com/api-platform/tutorials/secure-calls-your-api-through-api-key-validation

I am now trying this API with Try this API in Live Portal. In the API documentation required, if I specify the apikey as a query parameter, somehow I get the right response although I still get {isTrusted: true} with unknown status when I pass the wrong the apikey(shouldn't I get 401 response like the key is wrong or something?)

But, in the API documentation, when I specify the apikey inside header, I get {isTrusted:true} with unknown status whether or not I pass the right API key in Try this API.

The curl command that Try this API generates is correct because I can verify that by running the command in my terminal. But, only in Try this API console, it doesn't work. Am I missing anything? Thank you!

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

1 Answer

  • Sort: 
avatar image
0
Best Answer

Answer by Sai Saran Vaidyanathan   · Jul 13, 2020 at 03:31 PM

Hi @hyun jeon

This is due to CORS. Before hitting "Execute" in Try it now, please enable trace in Apigee proxy and also enable Developer tools on your browser. You will see an error due to CORS. You will also see a preflight OPTIONS call that gets called from the browser. This is common with calls made from browser (from another domain). To get this to work, you need to enable CORS. To enable - follow the steps mentioned here

NOTE: If you have added the Verify API Key policy in the Preflow, make sure you add a condition like this

<Step>
    <Name>verify-api-key</Name>
    <Condition>request.verb != "OPTIONS"</Condition>
</Step>

We don't want this policy executed for the OPTIONS call. Once this is done, try making the call from "Try it now".

Another note: Make sure you are hitting the "https" endpoint of the proxy

Comment
Add comment Show 15 · 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 hyun jeon · Jul 13, 2020 at 04:33 PM 0
Link

@ Sai Saran VaidyanathanThank you sir! CORS was indeed the issue; it failed at the preflight OPTIONS. So, I followed the steps you suggested and am getting the result when I pass the correct api key in the header. But if I could, could I also ask why I am still getting {isTrusted: true} with unknown status when I pass INCORRECT apikeys? Is it a normal behavior of Try this API? But I highly doubt it because in the development console, I am seeing CORS errors when an incorrect API key is passed. What should I do more?

avatar image Sai Saran Vaidyanathan ♦ hyun jeon   · Jul 13, 2020 at 05:18 PM 0
Link

HI @hyun jeon - please include the Add-CORS policy to the FaultRules. All the exceptions are caught using FaultRules

In your proxy endpoint config, add these

<FaultRules/>
    <DefaultFaultRule name="all">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Add-CORS</Name>
        </Step>
    </DefaultFaultRule>

This means it will add the CORS headers for the exception scenarios too

avatar image hyun jeon · Jul 13, 2020 at 04:41 PM 0
Link

And when I enable CORS by dragging the CORS Icon into the diagram of preflow of Target Endpoints (like the example in the page that you linked) I get

The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed

Any Idea what it might be?

avatar image Sai Saran Vaidyanathan ♦ hyun jeon   · Jul 13, 2020 at 05:19 PM 0
Link

Dont think you need this.

avatar image hyun jeon · Jul 13, 2020 at 07:27 PM 0
Link

@Sai Saran Vaidyanathan

Thank you again for your answer; I really appreciate it! But, I am still a little lost. For the initial problem, I was able to fix it by adding your suggestion below

<Step>
    <Name>verify-api-key</Name>
    <Condition>request.verb != "OPTIONS"</Condition>
</Step><br>

But the problem of receiving {isTrusted:true} persists on incorrect API keys. So I follow your suggestions of enabling CORS by checking "Add CORS headers" when creating the proxy, which results in the preflow diagram being like below (Isn't this what you mean by "enabling CORS" in your answer above? Please correct me if I am wrong)

However, with this CORS policy, I get {isTrusted:true} on both correct and incorrect API keys with the error on the console being "Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed."

Because of that, even when I add the Add-CORS policy to the FaultRules, I still get {isTrusted:true} with the same error on the console.

These are my settings, is there anything wrong? Again, I really appreciate you taking the time for my question!

3.jpg (68.9 kB)
avatar image Sai Saran Vaidyanathan ♦ hyun jeon   · Jul 13, 2020 at 07:37 PM 0
Link

@hyun jeon - I think your config is wrong. Please remove line 4 - 10 and add them to the Proxy endpoint code. On the left menu, click the default under "Proxyendpoint" and add it before Preflow

avatar image hyun jeon Sai Saran Vaidyanathan ♦ · Jul 13, 2020 at 07:48 PM 0
Link

@Sai Saran Vaidyanathan

Thank you again sir! By 4 - 10, would you mean

<FaultRules/>
    <DefaultFaultRule name="all">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Add-CORS</Name>
        </Step>
    </DefaultFaultRule>

If I remove this block from the config of "Add CORS" and add it to the Proxy endpoint code before Preflow, I get

I am not sure but I tried with lowercase like below

<FaultRules/>
    <DefaultFaultRule name="all">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>add-cors</Name>
        </Step>
    </DefaultFaultRule>
<br>

Though I was able to deploy, the problem persists..

Thank you!

Show more comments
avatar image hyun jeon · Jul 13, 2020 at 09:10 PM 0
Link

@Sai Saran Vaidyanathan

Thank you sir! I have ended up fixing the problem by putting together all the suggestions you have kindly provided! It turns out that I needed these 2 blocks of code in my default

<Step>
    <Name>verify-api-key</Name>
    <Condition>request.verb != "OPTIONS"</Condition>
</Step>

&&

<FaultRules/>
    <DefaultFaultRule name="all">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Add-CORS</Name>
        </Step>
    </DefaultFaultRule><br>

Which makes me wonder why I get CORS errors when I add these 2 blocks to my default

<Flows>
        <Flow name="OptionsPreFlight">
            <Request/>
            <Response>
                <Step>
                    <Name>AM-AddCORS</Name>
                </Step>
            </Response>
            <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
        </Flow>
</Flows>

&&

<RouteRule name="NoRoute">
        <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
    </RouteRule>

<br>

What are these? According to the documentation you linked earlier, they are supposed to help handle preflight requests. But With them being in default, I rather get CORS errors. Could I ask maybe why?

Thank you again for your help and kind suggestions!

avatar image Sai Saran Vaidyanathan ♦ hyun jeon   · Jul 13, 2020 at 09:19 PM 0
Link

Glad you got it working. I will try and explain each below

<Step>
    <Name>verify-api-key</Name>
    <Condition>request.verb != "OPTIONS"</Condition>
</Step>

The above it to execute the policy and if the condition evaluates to true, it executes the policy

<FaultRules/>
    <DefaultFaultRule name="all">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Add-CORS</Name>
        </Step>
    </DefaultFaultRule><br>

Any exception thrown by a policy in Apigee raises a fault (you can think it like an exception). To catch those you need to use the FaultRules to execute like catch block. Check this link for more info. DefaultFaultRule are the ones that executes after the FaultRules are executed.

<Flow name="OptionsPreFlight">
            <Request/>
            <Response>
                <Step>
                    <Name>AM-AddCORS</Name>
                </Step>
            </Response>
            <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
        </Flow><br>

is a Conditional flow that executes on a Condition. In the above block, it gets called with the Preflight OPTIONS call occur. And when that occurs, it sets the CORS headers in the response

<RouteRule name="NoRoute">
        <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
    </RouteRule><br>

RouteRule is used to determine the target endpoint where the request needs to be sent to. For the OPTIONS call, we dont need to send to a backend target. So we set it with no target endpoints. Compare this routerule with the default RouteRule you have in your proxy. For more info on Route Rules, check this link

In your case, when you passed an invalid API KEY, Apigee raised a fault and it went to the FaultRule,DefaultFaultRule section. And in that section, since the response did not include the CORS headers, the portal was not able to render the response. Hence we had to include the CORS Assign Message policy to the FaultRule as well.

hope the blocks and the explanation clarifies

avatar image hyun jeon Sai Saran Vaidyanathan ♦ · Jul 13, 2020 at 09:47 PM 0
Link

@Sai Saran Vaidyanathan

Wow, thank you so much for your thorough & concise explanation at such a moment when I was reading the documentations.

One last thing that bothers me though is the two blocks (Flow "OptionPreFlight" and RouteRule "NoRoute"). When I add either one or both to my default, I get CORS errors.

According to the documentation you pointed to earlier, they are supposed to help handle preflight requests. But it rather causes CORS errors. Would you please your share opinion as to maybe why? Because without them, it works perfectly fine on both valid and invalid api keys.

Show more comments

Follow this Question

Answers Answers and Comments

47 People are following this question.

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

Related Questions

can we create the service and publish using trail APIG vestion? 1 Answer

Self service on-boarding on developer portal for external user 2 Answers

Mock/sample requests and responses payload in the developer portal 2 Answers

CORS error - Request header field x-apikey is not allowed by Access-Control-Allow-Headers in preflight response 1 Answer

Integrated Developer Portal (become a developer) 1 Answer

  • 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
  • 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
  • Articles
  • Ideas
  • Badges