aws-wafv2: LoggingFilterProperty generating incorrect CloudFormation Template

[automartin5000]

Describe the bug

At some point since version 2.50 (I think), there seems to have been a breaking change to the CloudFormation resource being created by the aws-wafv2 LoggingFilterProperty resulting in the following error message:

#/LoggingFilter: required key [DefaultBehavior] not found
#/LoggingFilter: required key [Filters] not found
#/LoggingFilter: extraneous key [defaultBehavior] is not permitted
#/LoggingFilter: extraneous key [filters] is not permitted

This seems to be related to the wrong casing (see details below).

Expected Behavior

CloudFormation code that uses pascal casing as described in the API

Current Behavior

The following CloudFormation code is created with camel cased properties:

"LoggingFilter": {
     "defaultBehavior": "DROP",
     "filters": [
      {
       "requirement": "MEETS_ANY",
       "conditions": [
        {
         "actionCondition": {
          "action": "BLOCK"
         }
        },
        {
         "actionCondition": {
          "action": "COUNT"
         }
        }
       ],
       "behavior": "KEEP"
      }
     ]
    },

This results in the following error message when attempting to deploy:

#/LoggingFilter: required key [DefaultBehavior] not found
#/LoggingFilter: required key [Filters] not found
#/LoggingFilter: extraneous key [defaultBehavior] is not permitted
#/LoggingFilter: extraneous key [filters] is not permitted

Reproduction Steps

We're using the following code to build our logging configuration:

export abstract class LoggingFilterConfiguration {
  /**
   * Keep logs that don't match any of the specified filter conditions.
   * @param filters
   * @returns LoggingFilterConfiguration
   */
  public static defaultKeep(
    filters: any[],
  ): wafv2.CfnLoggingConfiguration.LoggingFilterProperty {
    return {
      defaultBehavior: LoggingFilterBehavior.KEEP,
      filters: filters,
    };
  }

  /**
   * Drop logs that don't match any of the specified filter conditions.
   * @param filters
   * @returns LoggingFilterConfiguration
   */
  public static defaultDrop(
    filters: any[],
  ): wafv2.CfnLoggingConfiguration.LoggingFilterProperty {
    return {
      defaultBehavior: LoggingFilterBehavior.DROP,
      filters: filters,
    };
  }
}

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.61.1

Framework Version

No response

Node.js Version

18

OS

Mac OS 13.1

Language

Typescript

Language Version

4.7.4

Other information

No response

[eloymg]

I think that exist the same bug with:

• wafv2.CfnWebACL.SingleHeaderProperty
• wafv2.CfnLoggingConfiguration.SingleHeaderProperty
  Generate the property with "name" no "Name" that is correct.

[pahud]

According to this cfnspec, I think the loggingFilter property should be a LoggingFilter type rather than any(described in the API reference). I need to discuss this internally with the team.

[pahud]

This issue is related to #23679 (comment) as described by @peterwoodworth. At this moment, as loggingFilter property in L1 is not strongly typed, you will need to capitalize the property to synthesize correct CFN template.

[peterwoodworth]

The way described above is the proper way to define this from now on. Sorry for any inconvenience, we're looking into making sure this doesn't happen again

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[JohannesTimmreck-MHP]

Hi @peterwoodworth,

I believe that this problem was not resolved in the fix(WAFv2): add patch to revert struct names #24651 as it did not modify the LoggingFilterProperty.

[peterwoodworth]

That's already been done before that PR here @JohannesTimmreck-MHP

aws-cdk/packages/@aws-cdk/cfnspec/spec-source/specification/000_cfn/500_Revert_To_Json_Types_patch.json

Line 510 in 5d52646

"operations": [

[JohannesTimmreck-MHP]

Hi @peterwoodworth,
as it seems the link you send corrected the LoggingFilterConfiguration, but it also does not mention the CfnLoggingConfiguration.LoggingFilterProperty, for which the error in regards to the mismatch of "DefaultBehavior"-"defaultBehavior" and "Filters"-"filters" properties still occurs.
I just tested the properties on the 2.74.0 version

[peterwoodworth]

The type that this construct originally expected still gets generated - you just shouldn't use the type because the construct doesn't want to accept this type anymore. The patch here is changing the type that CfnLoggingConfiguration expects for its loggingConfiguration property.

[JohannesTimmreck-MHP]

Ahh alright, thank you for the help!