Regression: multiline variable values accepted in v1 are rejected since v2

Backward compatibility regression: variable validation rejects newline characters since v2

Summary

Multiline values for Komodo variables were accepted in v1, and existing multiline values are still readable and interpolated correctly after upgrading.

However, since v2, creating or updating a variable containing newline characters is rejected.

Example:

TEST=TEST1
TEST2=TEST3

This worked in Komodo v1, but is rejected in Komodo v2.

This creates a backward-compatibility issue for installations that already contain multiline variables created under v1.

Reproduction

1. Go to Settings -> Variables
2. Create a variable, or edit an existing one
3. Set the value to:

TEST=TEST1
TEST2=TEST3

1. Click Update

The request is rejected.

A single-line value works correctly:

TEST=TEST1

Historical behavior

I checked the implementation in several v1 releases.

v1.10.0

UpdateVariableValue writes the value directly to MongoDB without validating its content.

v1.18.4

Same behavior.

v1.19.5

Same behavior.

As a result, multiline strings were accepted in v1.

Behavior since v2

Starting with v2.0.0, UpdateVariableValue validates the value before writing it:

validate_variable_value(&value)
    .status_code(StatusCode::BAD_REQUEST)?;

The current validation is:

pub fn validate_variable_value(value: &str) -> anyhow::Result<()> {
    StringValidator::default()
        .max_length(MAX_VARIABLE_VALUE_LENGTH)
        .validate(value)
        .context("Failed to validate variable value")
}

The issue is that StringValidator::default() rejects control characters by default:

if !self.skip_control_check {
    validate_no_control_chars(input)?;
}

and validate_no_control_chars() rejects characters for which char.is_control() is true:

if char.is_control() {
    return Err(anyhow!(
        "Control character at index {index}. Input: \"{input}\""
    ));
}

This includes newline characters.

The validation library also contains a test explicitly confirming this behavior:

assert!(validator.validate("hello\nworld").is_err());

Why this appears to be a regression

Existing multiline variables created under v1 still work after upgrading to v2.

They can still be:

• read from the database
• displayed in the UI
• interpolated
• used by stacks

But they can no longer be modified or recreated through the current API.

This leads to the following inconsistent state:

Existing multiline variable

Read            OK
Display         OK
Interpolation   OK
Use in stack    OK
Update          FAIL
Recreate        FAIL

The underlying storage and interpolation mechanisms therefore still support multiline strings. The restriction appears to come specifically from the validation layer introduced in v2.

Example use case

One useful pattern is to store a reusable environment block inside a Komodo variable:

hostname=authentik-ldap-int
AUTHENTIK_HOST=https://auth.example.com
AUTHENTIK_TOKEN=...

and interpolate it where needed.

Existing variables using this pattern continue to function after upgrading, but any attempt to modify them now fails because of the newline validation.

Expected behavior

Multiline variable values should remain supported for backward compatibility.

At minimum, newline characters should be allowed:

• LF (\n)
• optionally CRLF (\r\n)

It would still make sense to continue rejecting genuinely unsafe or unexpected control characters such as NUL.

I would therefore suggest allowing line breaks specifically rather than disabling all control-character validation.

Versions checked

• v1.10.0: multiline values accepted
• v1.18.4: multiline values accepted
• v1.19.5: multiline values accepted
• v2.0.0: multiline values rejected
• v2.3.3: multiline values rejected

Additional impact

This is particularly problematic for upgraded installations because legacy multiline values remain valid and usable, but become effectively immutable.

Opening an existing multiline variable and changing even a single character causes the update to fail.

It would therefore be useful either to restore support for multiline variable values or to explicitly handle or migrate existing legacy multiline values.