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>
🤖 Augment PR SummarySummary: Centralizes SQL
%, _, and \.
🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| 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.
escape_like_pattern() escapes %/_ using backslashes, but this query uses ESCAPE '|', so \%/\_ won’t be treated as escaped literals and matching/injection-hardening may not work as intended. Consider aligning the ESCAPE character with the escaping strategy used to build query_pattern.
🤖 Was this useful? React with 👍 or 👎
| 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.
This not contains branch escapes the value but doesn’t pass an escape character to notlike, unlike the other LIKE branches here. On databases where backslash isn’t the default LIKE escape, this can change behavior for inputs containing %, _, or \.
🤖 Was this useful? React with 👍 or 👎
| # Escape special characters in keyword to prevent SQL injection via LIKE wildcards | ||
| keyword_trimmed = keyword[:30] | ||
| escaped_keyword = escape_like_pattern(keyword_trimmed) | ||
| keyword_like_val = f"%{escaped_keyword}%" |
There was a problem hiding this comment.
This used to unicode-escape the keyword (to match JSON strings containing \uXXXX sequences from json.dumps); switching to only escape_like_pattern may regress searches for non-ASCII keywords in WorkflowRun.inputs/outputs. If those columns store escaped Unicode, the raw keyword may no longer match.
🤖 Was this useful? React with 👍 or 👎
2 participants
Benchmark PR from agentic-review-benchmarks#12