Redis Key-Value Assertion Storing Null Value

Products

• CA API Gateway

Issue/Introduction

While using the key-value assertion with Redis, I noticed that it is saving entries even when the key is null. I believe this behavior might not be ideal, as keys in Redis are expected to be valid and non-null.

Environment

11.1

Resolution

In Redis (the underlying data store for the Key-Value Assertion when Redis is used), keys must be non-null and non-empty strings. Redis itself does not allow a literal null key — if you try using the SET command with a null or empty string as the key in direct Redis CLI, it will reject it.

in Layer7’s Key-Value Pair Assertion, the policy logic may not validate the key variable at runtime. If the variable that resolves to the key is missing, empty, or null, the assertion may still attempt to connect to Redis and perform the operation, resulting in either:-

1. An empty-string key being used (""), which Redis does allow technically (not null, but empty string).

2. Or a key with a literal string "null" if your expression language resolves that way.

So by default, the Key-Value Pair Assertion does not reject or fail if the key resolves to empty or null. This is why it’s common practice in Layer7 to
add an explicit Comparison Assertion or Hardening Assertion before the Key-Value Pair Assertion.

Use the IsEmpty or IsNull operators to fail the request or skip the Redis call if the key variable is not valid.

So the best approach is to always validate variables that will be used as Redis keys.

Always validate variables that will be used as Redis keys:

plaintext
Copy
Edit
Comparison Assertion:
  - Expression1: ${your.key.variable}
  - Operator: Is Not Empty
  - On Fail: Raise Custom Fault or Reject Request
This ensures that the Gateway only stores valid key-value pairs.