[Richard Cadogan (arkin-nz)]

Why make this change?

• Addresses the contains / startswith / endswith part of [Enh]: Add basic string $filter functions #3240 (and the long-standing request in Add more OData expression support to $filter #936). It doesn't cover the regex, allow-regular-expressions or MCP parts of [Enh]: Add basic string $filter functions #3240.
  • REST $filter and database policies only support binary comparison operators. OData string functions parse, but fail at request time because ODataASTVisitor and ParameterAliasRewriter don't handle SingleValueFunctionCallNode. GraphQL filter already supports these functions.
  • It also extends them to database policies, which [Enh]: Add basic string $filter functions #3240 doesn't mention. The motivating case is hierarchical row-level access: each row stores a delimited list of manager IDs (|123456|957456|159854|), and a manager should see the rows where their own ID, a token claim, appears in that list.
  • Related: Database Policies - Support "in" filter for OData #2004 asks for the reverse shape (a multi-value claim containing a column value). This PR rejects that shape, so Database Policies - Support "in" filter for OData #2004 stays open.

What is this change?

• SQL (ODataASTVisitor): contains, startswith and endswith are translated to column LIKE @param. The search value must resolve to a non-empty string: a constant, a bound claim, or a concat of those. It is resolved in C#, LIKE wildcards are escaped with the same rules as the GraphQL filter (the escaping is moved into a shared SqlLikePattern), and the whole pattern is bound as one parameter with the length override GraphQL uses for LIKE. No claim value reaches the SQL text.
• Cosmos DB (ODataASTCosmosVisitor): the same functions map to the native CONTAINS/STARTSWITH/ENDSWITH(c.col, @param).
• Claim binding (ParameterAliasRewriter): recurses into function arguments so claim aliases inside them get bound, and treats a function call as a predicate so it isn't rewritten as ... eq true.
• Fail closed: the first argument must be a field. Other shapes (other functions such as tolower, field-to-field, a claim as the searched value, a null or empty value) throw. A non-string claim, such as a numeric ID, used in one of these functions gets a clear error saying claims must be strings. Policy failures surface as the existing 403 AuthorizationCheckFailed for both SQL and Cosmos DB; $filter failures as the existing 400 "$filter query parameter is not well formed." Comparing a function's result (startswith(title, 'A') eq true) is also rejected rather than translated, so FindTestWithUnsupportedFilterKeywords keeps passing unchanged.
• LIKE rendering: the visitor renders LIKE through a new IQueryBuilder.BuildLikePredicate, so each dialect decides how to escape. SQL Server adds ESCAPE '\', which covers mutations as well as reads, since database policies also apply to insert, update, delete and upsert. DWSQL has no ESCAPE support yet, so it rejects these functions. MySQL and PostgreSQL use plain LIKE, where \ is already the default escape character.
• REST field visitor: ODataASTFieldVisitor traverses function arguments, so columns referenced inside $filter functions still go through column-level authorization.

Example policy for the use case above:

"policy": {
  "database": "contains(@item.managerIds, concat(concat('|', @claims.mgr), '|'))"
}

Out of scope, noted for follow-up:

• DWSQL support. DwSqlQueryBuilder never adds an ESCAPE clause, not even for the existing GraphQL contains, so these functions are rejected for DWSQL until it does. I couldn't test against a warehouse.
• Converting numeric claims to strings inside these functions.
• Moving GraphQL filter LIKE onto BuildLikePredicate, so the SQL Server read path no longer needs its regex.
• in lists and other OData functions are still unsupported.

How was this tested?

• Integration Tests

• Unit Tests

• DatabasePolicyClaimBindingUnitTests (no database needed) covers the full claim → OData AST → SQL/Cosmos path:

  • a delimited concat claim bound as one parameter (%|123456|% for SQL, |123456| for Cosmos);
  • wildcard and quote escaping for all three functions;
  • combination with and;
  • fail-closed cases (claim as the searched value, field-to-field, null or empty value, unsupported function, function compared to true), for SQL and Cosmos DB;
  • DWSQL rejection, and a clear error for Integer32 and Integer64 claims, direct and inside concat;
  • the SQL Server read path adds ESCAPE to LIKE only once.

  These fail without the change.

• ODataASTVisitorUnitTests (SQL Server): $filter cases for contains, startswith, endswith and concat.

• All non-database tests pass (3,280). The TestCategory=MsSql suite was run against SQL Server 2025 in Docker. Before review, it was compared with unmodified main: 1,577 passed with this change against 1,573 without. After the review changes: 1,579 passed. In every run, the failures came from the local environment (mostly ConfigurationTests and hot-reload tests) and also happen without this change.

• Manual end-to-end check against SQL Server, with the policy above and AppService auth carrying an mgr claim:

  • manager 123456 reads exactly their rows;
  • |91234567| (a superstring) and 1234 (a substring) don't match;
  • claim 1_3456 doesn't match |1x3456|, so the wildcard is escaped;
  • a claim containing ' returns an empty result, not an error;
  • GraphQL update and REST delete succeed on own rows and return not-found on others' rows;
  • every executed LIKE carried ESCAPE '\'.

• PostgreSQL and MySQL were not run locally. Both use \ as the default LIKE escape character, which the existing GraphQL contains already relies on.

Sample Request(s)

Policy (as above), then:

GET /api/ManagedRecord
X-MS-API-ROLE: manager
X-MS-CLIENT-PRINCIPAL: <principal with claim mgr=123456>

returns only the rows whose managerIds contains |123456|.

REST $filter:

GET /api/Book?$filter=contains(title, 'Awesome')
GET /api/Book?$filter=startswith(title, 'Awe') and not endswith(title, 'book')

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Richard Cadogan (arkin-nz)]

@microsoft-github-policy-service agree company="Arkin"

[Copilot]

🟡 Changes recommended

DWSQL can evaluate authorization predicates incorrectly, and rejected Cosmos policies lack authorization-error translation.

2 open findings

• Reject DWSQL string functions without LIKE escaping · New
• Map Cosmos policy translation failures to authorization denial · New

What changed in this PR

Adds OData string filtering to DAB’s REST filters and database policies, partially addressing #3240 and #936.

Changes:

• Translates contains, startswith, and endswith into parameterized SQL and Cosmos predicates.
• Supports claim binding and constant concat, while preserving column authorization.
• Shares LIKE escaping with GraphQL and extends SQL Server mutation escaping.

File	Description
src/​Service.Tests/​UnitTests/​RelationalUpsertConcurrencyQueryBuilderTests.cs	Tests upsert policy escaping.
src/​Service.Tests/​UnitTests/​ODataASTVisitorUnitTests.cs	Adds string-filter translation cases.
src/​Service.Tests/​UnitTests/​DatabasePolicyClaimBindingUnitTests.cs	Tests claim binding, escaping, and rejection.
src/​Core/​Resolvers/​MsSqlQueryBuilder.cs	Adds escaping to mutation predicates.
src/​Core/​Parsers/​ParameterAliasRewriter.cs	Binds claims inside function arguments.
src/​Core/​Parsers/​ODataStringFunctionHelper.cs	Centralizes validation, folding, and escaping.
src/​Core/​Parsers/​ODataASTVisitor.cs	Generates parameterized LIKE predicates.
src/​Core/​Parsers/​ODataASTFieldVisitor.cs	Traverses function arguments for authorization.
src/​Core/​Parsers/​ODataASTCosmosVisitor.cs	Generates native Cosmos string predicates.
src/​Core/​Models/​GraphQLFilterParsers.cs	Reuses shared LIKE escaping.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[aaronburtle]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).

[aaronburtle]

Thanks for quickly addressing the comments, looks good!