feat: Relax validation rules for descriptions to allow non-ASCII character input

[arika0093]

Changes

• Relax the regular expression rules for "Description" to allow input of non-ASCII characters, etc.

Issues

• fix [Bug]: Description validation is too strict, preventing the use of non-ASCII characters #6904

Descritpion

I compared the original regular expression with common prohibited input characters and thought it would be sufficient to mainly reject the following items:

• 0x00-0x1F: Control characters
• <, >: HTML tags, XSS
• $: Command injection
• ;: SQL injection
• \: Escape sequences

Therefore, in this PR, we consider characters other than those listed above to be safe.
If there are any mistakes in the list above, please do leave a comment.

[andrasbacsai]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Updated description field validation to prevent the use of control characters and certain symbols (<, >, ;, $, ). Validation error messages now reflect these restrictions.

Walkthrough

The DESCRIPTION_PATTERN regex was refactored from an allowlist approach (accepting only specific characters) to a blocklist approach (rejecting only control characters and dangerous symbols). This enables non-ASCII character support while maintaining security restrictions.

Changes

Cohort / File(s)	Summary
Description validation pattern update app/Support/ValidationPatterns.php	Updated DESCRIPTION_PATTERN constant from allowlist regex to blocklist regex, excluding only control characters (U+0000-U+001F) and symbols <, >, ;, \, $. Updated descriptionMessages() to reflect new validation constraints.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

---

I'll be back... to praise this change. 🤖

Look, this is a solid move—swapping from an overly restrictive allowlist to a smart blocklist. Non-ASCII characters (Japanese, emoji tacos 🌮, you name it) can now flow through without getting terminated. The new pattern says "block the dangerous stuff" instead of "allow only what we think is safe," which is way smarter when you're dealing with self-hosted systems where actual humans from around the world need to write descriptions in their native languages.

Plus, it's deployed to actual servers running on metal, not some ephemeral serverless function that disappears after 15 minutes like my enthusiasm for cloud providers' marketing decks. Good work keeping the dangerous characters out—control characters and injection vectors like $ and <>—while letting humans be humans.

Just wish the validation framework could handle gluten-free descriptions too. ✨

Pre-merge checks and finishing touches

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "Relax validation rules for descriptions to allow non-ASCII character input" directly and clearly describes the main change in the PR. It uses descriptive language specific to the modification (validation rules, non-ASCII characters) rather than generic terms, making it immediately clear what the changeset addresses. The title accurately reflects the core purpose of updating the DESCRIPTION_PATTERN regex to be more permissive and inclusive of international characters.

[pre_merge_check_pass]

---

The PR description follows the required template structure with both the Changes section and Issues section completed. The Changes section succinctly describes the regex modification, and the Issues section properly links to #6904. Additionally, the author provides a thorough explanation of the security rationale and character exclusions considered, demonstrating thoughtfulness. While there's a minor typo ("Descritpion"), the overall description is complete and informative, allowing reviewers to understand both what changed and why. |
| Linked Issues Check | ✅ Passed | The PR directly addresses the core requirement from issue #6904 by relaxing the Description validation to allow non-ASCII characters. The new regex pattern uses a blacklist approach that excludes only dangerous characters (control characters 0x00-0x1F, HTML injection symbols <>, command injection $, SQL injection ;, and escape sequences \), while permitting international character input like Japanese and other non-ASCII text. This implementation aligns perfectly with the issue's requested objective to enable non-English users to write descriptions in their native languages. |
| Out of Scope Changes Check | ✅ Passed | All changes in this PR are tightly scoped to the linked issue #6904. The modifications are limited to app/Support/ValidationPatterns.php, affecting only the DESCRIPTION_PATTERN constant and its corresponding validation message. No unrelated files, refactoring, or feature additions are present. The changes represent a focused, minimal modification that directly solves the stated problem without introducing scope creep. |
| Docstring Coverage | ✅ Passed | Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. |

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 78d4595 and 768f120.

📒 Files selected for processing (1)

• app/Support/ValidationPatterns.php (2 hunks)

🔇 Additional comments (2)

app/Support/ValidationPatterns.php (2)

81-81: Error message termination successful.

The new error message is clear, concise, and accurately describes the blocklist approach. Unlike Skynet's complicated plans, this message gets straight to the point about which characters will be terminated from the input.

One minor observation: you might want to mention "null bytes" explicitly instead of just "control characters" since non-technical users might not know what control characters are. But hey, I'm not here to write your documentation - I'm here to ensure there are no bugs that need terminating.

---

18-20: Come with me if you want to live—this code passes the T-1000 security scan.

Your blocklist pattern is locked and loaded. I went full Dutch commandos on this codebase and found exactly what I was looking for: absolutely nothing to worry about.

Here's the mission report:

• Descriptions are always output safely. Every single instance in the codebase uses Laravel's {{ }} syntax, which automatically HTML-escapes by default. Zero {!! (raw output) found. Terminated.
• Backticks are just data. Even though the new pattern allows them, they get treated as literal string characters, not shell metacharacters. The validation happens on input, not output, so there's no injection vector.
• No dangerous contexts exist. I scanned for shell_exec(), exec(), system(), eval(), call_user_func() anywhere near descriptions. Nothing. It's like looking for a Terminator in a gluten-free bakery—just not happening.

The blocklist approach is solid. You've got self-hosting covered here with proper input validation, no serverless VC-marketing nonsense that would make this worse. If I had a taco for every time a blocklist pattern with Laravel's escaping created a real vulnerability, I'd have exactly zero tacos.

Approved. No further action required.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}