topic show-access-rulebase API request: data of "creation-time" and "modification-time" the same. in API / CLI Discussion

show-access-rulebase API request: data of "creation-time" and "modification-time" the same.

fabiankoch — Fri, 29 Mar 2024 11:15:55 GMT

Hi,

I am trying to fetch data of all rules, which got created within the last year.

As far as I can see is that the "creation-time" field of every rule gets overwritten by the same value which stands in "modification-time".

Is this a known bug or is it intentional?

https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/show-access-rulebase~v1.9.1%20

Kind Regards,

Fabian

Re: show-access-rulebase API request: data of "creation-time" and "modification-time&

Bob_Zimmerman — Fri, 29 Mar 2024 15:14:07 GMT

The only time I've seen the creation-time be inaccurate is when you upgrade a management with existing rules to R80+. The creation-time in that case reflects when you upgraded rather than when the rule was originally created on R≤77. I just confirmed with this command that I have plenty of rules on R81.10 and R81.20 managements which were modified after being created:

mgmt_cli -f json -r true show access-rulebase \ uid 00001111-2222-3333-4444-555566667777 \ limit 500 offset 0 \ | jq -c '.rulebase[] | if has("rulebase") then .rulebase[]|. else . end | select(."meta-info"."creation-time"."iso-8601" != ."meta-info"."last-modify-time"."iso-8601") | [.uid,."meta-info"."creation-time"."iso-8601",."meta-info"."last-modify-time"."iso-8601"]'

Of course, you should replace my fake UUID (00001111-2222-3333-4444-555566667777) with the real UUID of one of your access layers. Also adjust the offset to sweep through the layer as needed.

Re: show-access-rulebase API request: data of "creation-time" and "modification-time&

fabiankoch — Wed, 03 Apr 2024 13:31:32 GMT

For me, it is currently incomprehensible according to which behavior the data changes.

That makes it really difficult to rely on that data, because you don't know if the data is correct and consistent.

I will now check some of the newer rules and their dates to see if they are correct.

Thank you for your reply to my issue.