fix(api): refactors the SQL LIKE pattern escaping logic to use a centralized utility function, ensuring consistent and secure handling of special characters across all database queries.#12
fix(api): refactors the SQL LIKE pattern escaping logic to use a centralized utility function, ensuring consistent and secure handling of special characters across all database queries.#12
Conversation
…ralized utility function, ensuring consistent and secure handling of special characters across all database queries. Signed-off-by: NeatGuyCoding <15627489+NeatGuyCoding@users.noreply.github.com>
…logic Signed-off-by: NeatGuyCoding <15627489+NeatGuyCoding@users.noreply.github.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe99d63a96
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| sql = f""" | ||
| SELECT TOP {top_k} id, text, meta | ||
| FROM {self.schema}.{self.table_name} | ||
| WHERE text LIKE ? | ||
| WHERE text LIKE ? ESCAPE '|' | ||
| """ |
There was a problem hiding this comment.
Here the query uses ESCAPE '|', but the new escape_like_pattern helper always escapes with backslashes. Because the SQL explicitly sets the escape character to |, any backslashes in query_pattern are treated as literal characters, so %/_ in user input will still act as wildcards. This means a search for e.g. 50% will match 500 or 50abc instead of the literal percent, which defeats the intended hardening and can broaden results unexpectedly. Consider either switching the SQL to ESCAPE '\\' or having the helper escape with | for this backend.
Useful? React with 👍 / 👎.
| case "not contains": | ||
| filters.append(json_field.notlike(f"%{value}%")) | ||
| escaped_value = escape_like_pattern(str(value)) | ||
| filters.append(json_field.notlike(f"%{escaped_value}%")) |
There was a problem hiding this comment.
The not contains branch now escapes % and _ with backslashes, but the resulting notlike call omits the escape argument. On databases where backslash is not the default escape (or where NO_BACKSLASH_ESCAPES is enabled), the backslashes are literal and %/_ still behave as wildcards, so values like 50% will not be filtered correctly. Other branches in this function add escape="\\", so this path is inconsistent and can return incorrect results for inputs containing % or _.
Useful? React with 👍 / 👎.
2 participants
Benchmark PR from agentic-review-benchmarks#12