How to create test conditions for verify api key errors that are possible.

[#1]

Since api keys are where new API uses will first have trouble, we are trying to have the system give the best messages possible. We have the following fault rule:

        <FaultRule name="protocol_and_api_key_faults">
            <Step>
                <Name>fault_invalid_key</Name>
                <Condition>(fault.name="InvalidApiKey")</Condition>
            </Step>
            <Step>
                <Name>fault_missing_key</Name>
                <Condition>(fault.name="FailedToResolveAPIKey")</Condition>
            </Step>
            <Step>
                <Name>fault_insufficient_key_permissions</Name>
                <Condition>(fault.name="InvalidApiKeyForGivenResource")</Condition>
            </Step>
            <Step>
                <Name>fault_key_not_approved</Name>
                <Condition>(fault.name="ApiKeyNotApproved")</Condition>
            </Step>
            <Step>
                <Name>fault_invalid_client_app</Name>
                <Condition>(fault.name="invalid_client-app_not_approved")</Condition>
            </Step>
            <Step>
                <Name>fault_developer_inactive</Name>
                <Condition>(fault.name="DeveloperStatusNotActive")</Condition>
            </Step>
            <Step>
                <Name>fault_company_inactive</Name>
                <Condition>(fault.name="CompanyStatusNotActive")</Condition>
            </Step>
        </FaultRule> 

The first three are easy to test.

ApiKeyNotApproved and invalid_client-app_not_approved seem like they should be easy, but in testing with a developer app that has approval that is still pending, we are seeing InvalidApiKeyForGivenResource rather than one of the expected not approved faults.

I have no idea how to test or how the not active faults might occur.

How do I create conditions to test these?

[#2]

@George - Yes, I was able to reproduce what you are trying to do and you are correct. It does default to "InvalidApiKeyForGivenResource". However I was able to get the correct one for an inactive developer - keymanagement.service.DeveloperStatusNotActive.

Consider an app having access to several products. Since you can individually revoke keys for a particular product and have a pending to be approved keys for just a subset of products, we have the generalized error message. But you are correct it is absolutely fair to desire a distinct error message (fault) for each of these use cases. I will investigate further and let you know if there is some other way to deal with this.

[#3]

Thanks for the quick response. How did you set conditions to create the inactive developer?

[#4]

So, if you trace your verify api key policy, there are a bunch of variables created that you can see on the trace. These variables can be referenced in context of the entire message. So the variable for me was

oauthV2.Verify-API-Key-1.fault.name=	keymanagement.service.DeveloperStatusNotActive

Where "Verify-API-Key-1" is the name of my policy. So putting the above condition in the fault rule would satisfy this use case and you could set a custom error code etc..

[#5]

So I'd like to be able to test that the inactive conditions occur and are detected properly. So are you saying that rather than setting some conditions somehow in Edge UI to cause the DeveloperStatusNotActive condition, you set the fault.name variable as you describe to cause the fault to occur? I already have what seems like it should be the correct fault rule conditional, but have no way to test it at present.