Skip to content

test: prove allowed_ips is ignored on key and policy level#7970

Open
probelabs[bot] wants to merge 1 commit intomasterfrom
test-allowed-ips-key-level
Open

test: prove allowed_ips is ignored on key and policy level#7970
probelabs[bot] wants to merge 1 commit intomasterfrom
test-allowed-ips-key-level

Conversation

@probelabs
Copy link
Copy Markdown
Contributor

@probelabs probelabs bot commented Apr 4, 2026

Problem / Task

A user reported that allowed_ips (IP Binding per Key) is not working and is being overridden by policy. We need a test to prove whether it works or is ignored.

Changes

Added user/session_allowed_ips_test.go with two tests:

  • TestSessionState_AllowedIPs_Ignored: Proves that allowed_ips is completely ignored when unmarshaling a SessionState (Key).
  • TestPolicy_AllowedIPs_Ignored: Proves that allowed_ips is completely ignored when unmarshaling a Policy.

This confirms that allowed_ips is strictly an API-level feature (APIDefinition) and is not natively supported for individual keys or policies.

Testing

  • Ran go test -v ./user -run TestSessionState_AllowedIPs_Ignored
  • Ran go test -v ./user -run TestPolicy_AllowedIPs_Ignored
    Both tests pass, confirming the behavior.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 4, 2026

🚨 Jira Linter Failed

Commit: 13e0158
Failed at: 2026-04-04 07:29:33 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details
failed to validate branch and PR title rules: branch name 'test-allowed-ips-key-level' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

  • Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
  • Verify your PR title matches the branch's Jira ticket ID
  • Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

@probelabs
Copy link
Copy Markdown
Contributor Author

probelabs bot commented Apr 4, 2026

This PR adds tests to confirm that the allowed_ips field is intentionally ignored when defined at the individual key (SessionState) and policy (Policy) levels. This clarifies that IP allow-listing is a feature configured exclusively at the API level (APIDefinition), not on a per-key or per-policy basis.

Files Changed Analysis

  • user/session_allowed_ips_test.go (Added): A new test file containing two test cases:
    • TestSessionState_AllowedIPs_Ignored: Verifies that allowed_ips in a JSON payload is discarded when unmarshaling into a SessionState object.
    • TestPolicy_AllowedIPs_Ignored: Verifies the same behavior for the Policy object.

The changes are purely additive, introducing 64 lines of test code with no deletions.

Architecture & Impact Assessment

  • What this PR accomplishes: It introduces regression tests to prevent future misunderstandings or bugs related to the scope of the IP allow-listing feature. It programmatically documents that allowed_ips is not supported for keys or policies, reinforcing that this is an API-level configuration.

  • Key technical changes introduced: Two new Go tests are added that unmarshal JSON strings containing an allowed_ips field into SessionState and Policy structs and then assert that the field's data is not present in the resulting objects.

  • Affected system components: No production code is changed, so there is no impact on runtime components. The change primarily affects developer understanding and provides clarity on the feature's correct usage within the system's configuration.

Scope Discovery & Context Expansion

  • The tests confirm that the SessionState and Policy structs in the user package do not have an allowed_ips field and therefore ignore it during standard JSON deserialization.
  • While ignored at the key and policy level, the allowed_ips feature is fully supported at the API level. The field is defined in the APIDefinition struct, specifically within the proxy settings.
  • This distinction is critical: IP restrictions can be applied to an entire API, but not granularly to specific keys or policies that have access to that API. Any attempt to do so will be silently ignored.
Metadata
  • Review Effort: 1 / 5
  • Primary Label: chore

Powered by Visor from Probelabs

Last updated: 2026-04-04T07:30:02.991Z | Triggered by: pr_opened | Commit: 13e0158

💡 TIP: You can chat with Visor using /visor ask <your question>

@probelabs
Copy link
Copy Markdown
Contributor Author

probelabs bot commented Apr 4, 2026

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

\n\n

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.


Powered by Visor from Probelabs

Last updated: 2026-04-04T07:29:58.633Z | Triggered by: pr_opened | Commit: 13e0158

💡 TIP: You can chat with Visor using /visor ask <your question>

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 4, 2026

API Changes

no api changes detected

@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented Apr 4, 2026

Quality Gate Failed Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

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.

1 participant