Incorrect message for invalid/missing subscription key using policy fragment with cors & Users shouldn't be able to send requests when not subscribed.

[Ledger94]

Every bug report should have precise description and reproduction steps; console traces or source code references are appreciated.

For assistance requests, contact Azure support or submit a post on Stack Overflow. We don't provide support through GitHub Issues. Feature requests can be raised on the Azure Feedback Forum.

Bug description

1. Incorrect message is showing when the subscription key is incorrect or missing. Cors policy has been set using policy fragment and it works as expected with the correct subscription key. This isn't an issue when not using policy fragments. (setting Cors in API scope without policy fragment)

Issue:

Expected Response:

2. Users shouldn't be able to send requests for APIs within products that require subscription keys, it is possible to do this currently. There should be some kind of message/error letting the user know that a subscription is required for the API like in old portal.

New Portal Ex:

Old Portal Ex:

Reproduction steps

First Bug:

1. Create policy fragment that has cors policy.
2. Add cors policy fragment to API scope.
3. Go to api-details page for an API that you are subscribed to test with correct subscription key. (It should work).
4. Test with incorrect subscription key (Cors error).
5. Update Cors without policy fragement.
6. Test again with incorrect subscription key (expected behavior 401 response).

Second Bug:

1. Go to api-details page for an API whos product requires a subscription key and you are not subscribed to it.
2. Click try it for pop up.
3. Test API without inputting subscription key (It should allow you to send request).

Expected behavior

1. Incorrect message is displaying related to cors when using a policy fragment that contains cors policy. It should work the same whether or not cors is in a policy fragment.
2. For APIs whos product requires a subscription key, it shouldn't be possible to test it without inputting a subscription key.

Is your portal managed or self-hosted?

Self-hosted (Managed has same issue)

Release: 2.23.0

Environment

Google Chrome

[ghost]

@Ledger94, thank you for opening this issue. We will triage it within the next few business days.

[malincrist]

Hello @Ledger94, I am not able to reproduce the issue you are describing. As long as the CORS policy is set correctly, I get a 401 in case I send the request with an incorrect subscription key or with no subscription key.

Could you please share your instance name and the policy fragment that you used for this configuration to [email protected] so we can investigate this further?

[Ledger94]

Hi @malincrist, did you use a policy fragment when setting cors. It is only reproduceable using a policy fragment.

Ex API policy:

<policies>
    <inbound>
        <base />
        <include-fragment fragment-id="cors-global" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

policy fragment:

<fragment>
	<cors>
		<allowed-origins>
			<origin>*</origin>
		</allowed-origins>
		<allowed-methods>
			<method>*</method>
		</allowed-methods>
		<allowed-headers>
			<header>*</header>
		</allowed-headers>
		<expose-headers>
			<header>*</header>
		</expose-headers>
	</cors>
</fragment>

Also were you able to reproduce the issue that allows users to try and send a requests for APIs that requires a subscription key without subscribing. It still returns a 401 error as expected but users shouldn't be able to send the request.

[malincrist]

Hello @Ledger94 ,

did you use a policy fragment when setting cors. It is only reproduceable using a policy fragment.

yes, that's how I tried. I tried with both policy fragment for CORS and policy for CORS, but I still can't reproduce it.. are you getting any errors in the console when sending this request? is there any other information you can provide us that may help reproduce this issue?

Also were you able to reproduce the issue that allows users to try and send a requests for APIs that requires a subscription key without subscribing. It still returns a 401 error as expected but users shouldn't be able to send the request.

yes, this is currently in progress, we will keep you updated on the progress.

[Ledger94]

Hello @malincrist,

The error I'm getting in the console is "net::ERR_FAILED 401 (Access Denied)". Which is expected since the subscription key is incorrect. The problem is it shouldn't be showing a CORS error.

I was able to reproduce the CORS error in a different way of which I'll explain how:

1. Set validate-jwt policy in the product policy (It works fine within the API policy)
2. Send an incorrect Authorization token.
3. Same CORS error will show up.

Ex policy within product:

<validate-jwt header-name="Authorization" failed-validation-httpcode="403" failed-validation-error-message="Invalid Token" require-expiration-time="true" require-signed-tokens="true" clock-skew="20">
    <openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
    <audiences>
        <audience>{{audience}}</audience>
    </audiences>
    <issuers>
        <issuer>{{issuer}}</issuer>
    </issuers>
</validate-jwt>

I was looking at the file: src/components/operations/operation-details/ko/runtime/operation-console.ts. It will throw a cors error on any response error, which doesn't seem correct. This would explain why it is showing a CORS error even though CORS has been set to allow everything. It also seems to have different behavior based of the policy's scope. Using the exact same policy in different scopes produces an error (Ex: policy fragment, product scope).