[ BUG ] FirewallPolicy.performFirewallPoliciesAction returns 500 error with 'add-rule-group'.

[api-clobberer]

Describe the bug
DocString shows 'add-rule-group' and 'remove-rule-group' as available options. However, in '_allowed_actions' var within the relevant function, these actions are absent. So the function returns a 500 error instead. If I manually add in the actions, it instead returns a 400 error.

To Reproduce
from falconpy import FirewallPolicies
client = FirewallPolicies()
rg = "target FW rule group"
pol = "target FW policy"
response = client.perform_policies_action(action_name = 'add-rule-group', ids = pol, group_id = rg)
response output:
{'status_code': 500, 'headers': {}, 'body': {'errors': [{'message': 'Invalid value specified for action_name parameter.'}], 'resources': []}}

Again, above error is result of action not being in '_allowed_actions' var. Manually adding these actions does not fix the issue, just instead returns 400 error from server.

Expected behavior
See below output for what happens when following the same steps, but instead trying to use the 'add-host-group' action. This is about what I'd expect to see from the 'add-rule-group' action:
from falconpy import FirewallPolicies
client = FirewallPolicies()
hg = "target host group"
pol = "target FW policy"
response = client.perform_policies_action(action_name = 'add-host-group', ids = pol, group_id = hg)
Reponse output:
'{'status_code': 200, 'headers': {'Server': 'nginx', 'Date': 'Fri, 27 Oct 2023 15:24:17 GMT', 'Content-Type': 'application/json', 'Content-Length': '915', 'Connection': 'keep-alive', 'Content-Encoding': 'gzip', 'Strict-Transport-Security': 'max-age=15724800; includeSubDomains, max-age=31536000; includeSubDomains', 'X-Cs-Region': 'us-2', 'X-Cs-Traceid': '...', 'X-Ratelimit-Limit': '6000', 'X-Ratelimit-Remaining': '5999'}, 'body': {'meta': {'query_time': 0.087387752, 'trace_id': '...'}, 'resources': [{...}]'

Environment (please complete the following information):

• OS: MacOS Ventura 13.6
• Python: 3.11.5
• FalconPy: 1.3.2

[jshcodes]

Hi @api-clobberer -

Fix for this will be included in the 1.3.3 update currently undergoing unit testing.

This is a good catch, thank you for reporting this issue! 🙇

[api-clobberer]

Hi @api-clobberer -

Fix for this will be included in the 1.3.3 update currently undergoing unit testing.

This is a good catch, thank you for reporting this issue! 🙇

Sheesh! Thank you more for getting on this so quick!

[api-clobberer]

FYI:

While this PR did fix the 500 error, it now returns a 200, with an empty resources field in the body. When I check if the rule groups were added to the policy as I'd expect, they are indeed not added. Difference is now I don't get an error to tell me it's broken.

[jshcodes]

FYI:

While this PR did fix the 500 error, it now returns a 200, with an empty resources field in the body. When I check if the rule groups were added to the policy as I'd expect, they are indeed not added. Difference is now I don't get an error to tell me it's broken.

I have recreated this issue using both the latest version of the SDK and the public swagger interface. I've also confirmed the SDK is crafting the payloads as per the swagger specification.

Thank you for letting us know about this issue. I'm reaching out to the internal team for this API operation to investigate. Stay tuned.

[jshcodes]

Reopening to track operation behavior issue.

[jshcodes]

Hi @api-clobberer -

Did some digging, and the add-rule-group and remove-rule-group actions should be performed by leveraging the update_policy_container operation from within the FirewallManagement Service Class. While these two actions are listed in the swagger for the performFirewallPoliciesAction operation, they are still unavailable via this operation at this time. The Service Class and documentation has been updated to reflect this.

Thank you for identifying this issue! 🙇

Note

I found a related bug while researching this issue. Upgrade to v1.3.4 to leverage body payload abstraction using the update_policy_container operation.