fix(validation): reject reserved FQN characters in entity and column names

[jaya6400]

Describe your changes:

Fixes #23268

I updated the regex patterns in JSON schema definitions to block reserved
FQN separator characters (::, >, ") and newlines (\n) from being
used in entity and column names.

The backend was accepting entity names with special characters like double
quotes and newlines, which caused issues in FQN construction since these
are reserved separator characters in OpenMetadata's FQN system.

Changes made:

• openmetadata-spec/src/main/resources/json/schema/type/basic.json — updated pattern for entityName and testCaseEntityName
• openmetadata-spec/src/main/resources/json/schema/entity/data/table.json — updated pattern for columnName

Pattern changed from ^((?!::).)*$ to ^((?!::)[^>"\x00-\x1f])*$

Unit Test: #27521 (comment)

Type of change:

• Bug fix

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes #23268: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

Migration scripts are not needed for this change as it only tightens input validation at the schema level. Existing data is not affected — only new entity creation requests will be validated against the updated pattern.

---

Summary by Gitar

• Validation enhancement:
  • Added regex support to block ASCII control characters \x00-\x1f in entityName, testCaseEntityName, and columnName schema definitions.

_{This will update automatically on new commits.}

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Reserved FQN characters are now rejected in entity and column names, resolving the previous issue where control characters like \r were not properly blocked. No further issues found.

✅ 1 resolved

✅ Edge Case: Pattern does not block \r or other control characters

📄 openmetadata-spec/src/main/resources/json/schema/type/basic.json:127 📄 openmetadata-spec/src/main/resources/json/schema/type/basic.json:133 📄 openmetadata-spec/src/main/resources/json/schema/entity/data/table.json:238
The new pattern ^((?!::)[^>" ])*$ explicitly blocks (newline) but doesn't block \r (carriage return) or other control characters (e.g., , \0). A carriage return \r in an entity name could cause similar FQN construction/parsing issues as , and control characters in names are almost certainly unintentional.

Note that the original . metacharacter already excluded by default in most regex engines (including Java's without DOTALL), so the explicit in the character class is redundant but documents intent. However, \r was also excluded by . in the original pattern but is not excluded by the new [^>" ] character class — so this change actually loosens the restriction for \r.

This is because . matches everything except (and sometimes \r), but [^>" ] matches everything except >, ", and — including \r and other control characters.

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[jaya6400]

Local pattern validation test:
Tested the updated regex ^((?!::)[^>"\x00-\x1f])*$ against the exact payload from the issue and other edge cases.

Bash command used: test-regex.txt
All reserved FQN characters and control characters are correctly rejected. Valid entity names pass through without issue.

Full CI will run once safe to test label is applied.