Skip to content

Test: target DURATION - 010 #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Sebitosh
Copy link
Contributor

@Sebitosh Sebitosh commented May 6, 2025

Description

#27

Test on target DURATION. I wrote this test to demonstrate some capabilities of the framework (it uses both the ACTIONS macro and the before generation feature).

The idea is to set a variable to 0 before starting, and then to check if the current DURATION for the phase (1 to 5) is greater than that. If it is, update the variable to the value of the matched DURATION (using MATCHED_VAR) such that the next check being performed is comparing the duration between phases. In summary, the checks are:

for phase 1: DURATION in phase 1 > 0

for phase 2-5: DURATION in phase N > DURATION in phase N-1

Assessment on V2

The 5 generated unit tests pass with no issues.

Assessment on V3 (using the not yet merged infra in #24 )

The 5 tests fail. The reason I believe is because of the difference of time granularity between V2 and V3. For V2, DURATION is evaluated as an int in microseconds. For V3, DURATION looks like it is evaluated as a float in milliseconds. This means that comparing DURATION with operator gt has a behavior that is not functional and that, to me, could be reconsidered. Here is what I can retrieve from the debug log:

[174653147029.073614] [/status/200] [4] (Rule: 100094) Executing operator "Gt" with param "0" Was: "" against DURATION.
[174653147029.073614] [/status/200] [9] Target value: "0.001536" (Variable: DURATION)
[174653147029.073614] [/status/200] [4] Rule returned 0.
[174653147029.073614] [/status/200] [9] Matched vars cleaned.

The question is: does the test I wrote correctly assess the DURATION target, and if so should the behavior in V3 be changed ? If not, how should the DURATION target be tested ?

@airween
Copy link
Member

airween commented Jun 1, 2025

The question is: does the test I wrote correctly assess the DURATION target, and if so should the behavior in V3 be changed ?

Probably we should align the behavior of DURATION in v3, because in case of v2 (as you mentioned above) the value is in microseconds. See the explained differences:

If not, how should the DURATION target be tested ?

Good question. I've never used this target, I assume the variable values are different between in two versions, so if the DURATION value is 1 sec, then it represents as 1000 in v3 and 1000000 in v2, right?

Probably we can skip this later.

@Sebitosh
Copy link
Contributor Author

Sebitosh commented Jun 1, 2025

if the DURATION value is 1 sec, then it represents as 1000 in v3 and 1000000 in v2, right?

I am not sure how I could verify this, but if in v3 it is stored as a float I would assume it is represented as 1000.0 ? I am to unfamiliar with the libmodsecurity3 codebase for the moment, but I am curious if it has any impact on use with numeric comparison operators such as @gt and @eq

Signed-off-by: Sebitosh <soloplayerdiablo@gmail.com>
@Sebitosh Sebitosh force-pushed the test-target-duration branch from bf9a532 to ea2b49d Compare June 1, 2025 20:39
@Sebitosh
Copy link
Contributor Author

Sebitosh commented Jun 1, 2025

Rebased & regenerated

Probably we can skip this later.

I was thinking about a feature similar to the --exclude flag of go-ftw or the overrides files used by CRS to disable tests that are known to fail. I'll propose it when I come up with something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants