Skip to content

Azure Application Gateway WAF Policy REST and CLI have misspelling of the word "Condition" in negationConditon in Custom Rule #31807

@erikhjensen

Description

@erikhjensen

Describe the bug

When we run az network application-gateway waf-policy show, and when we see the REST Docs: they use a field negationConditon to indicate that the condition should be inversed as a boolean.

See here: https://learn.microsoft.com/en-us/rest/api/application-gateway/web-application-firewall-policies/create-or-update?view=rest-application-gateway-2024-05-01&tabs=HTTP#matchcondition.

the field name "negationConditon" is misspelled and on that REST document page its description does spell "Condition" properly.

When we review the PowerShell implementation - the spelling is correct: https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/configure-waf-custom-rules#create-the-application-gateway.

When AzureCLI expects a custom object for this field, I think that there may be some mistranslation of the object that the Azure CLI method expects to what the REST expects, possibly exacerbated by the misspelling.

this is the output of the show command and this aligns w/ the REST docs so it appears the CLI returns what the REST team provides
"customRules": [ { "action": "Allow", "matchConditions": [ { "matchValues": [ "/_framework/icudt_EFIGS.dat" ], "matchVariables": [ { "variableName": "RequestUri" } ], "negatonConditon": false, "operator": "Contains", "transforms": [] } ], "name": "test-custom-rule", "priority": 10, "ruleType": "MatchRule", "state": "Enabled" } ]

However, if you want to use a structure like this to update the rule, the structure is different. This suggests the CLI implementation has a model object that expects different values, see here for an example that looks correct but which still fails on the "negation condition" aka "negation conditon". It actually expects a value of "negate"

"customRules": [ { "action": "Allow", "matchConditions": [ { "values": [ "/_framework/icudt_EFIGS.dat" ], "variables": [ { "variableName": "RequestUri" } ], "negationCondition": false, "operator": "Contains", "transforms": [] } ], "name": "test-custom-rule", "priority": 10, "ruleType": "MatchRule", "state": "Enabled" } ]

the difference lies with "variables" replacing "matchVariables" and "values" replacing "matchValues"

Related command

az network application-gateway waf-policy show or az network application-gateway waf-policy update.

Errors

When I try to use "update" it says:
Failed to parse '--custom-rules' argument: Model 'AAZObjectArg' has no field named 'negationConditon'
and when I correct the misspelling it also says the property is wrong:
Failed to parse '--custom-rules' argument: Model 'AAZObjectArg' has no field named 'negationCondition'

Issue script & Debug output

Is this required?

Expected behavior

The model object expected by the Azure CLI should behave in a less opaque fashion when translating to REST under the hood and hopefully the misspelling of the word Condition can be sent to the REST team to correct.

Environment Summary

azure-cli 2.74.0 *

core 2.74.0 *
telemetry 1.1.0

Extensions:
ml 2.37.1
ssh 2.0.6

Dependencies:
msal 1.32.3
azure-mgmt-resource 23.3.0

Additional context

No response

Metadata

Metadata

Assignees

Labels

Auto-AssignAuto assign by botAuto-ResolveAuto resolve by botAzure CLI TeamThe command of the issue is owned by Azure CLI teamNetworkaz network vnet/lb/nic/dns/etc...customer-reportedIssues that are reported by GitHub users external to the Azure organization.questionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions