Summary
Title == salt does not throw today. QueryKit reads the unquoted word salt as the literal text salt, the same as Title == "salt". This is inconsistent with the README, which said this throws a ParsingException (corrected in a separate PR).
The risk
The parser already treats an unquoted word as a possible property reference on the right side of a comparison, for example Rating > Author.Score. An unquoted string value uses the same grammar position. If a consumer later adds a property named Salt to their entity, the exact same filter text Title == salt silently changes meaning, from a literal string comparison to a property-to-property comparison. No exception, no warning.
Proposed options for the next major version
Pick one:
- Require double quotes around every string value. An unquoted word on the right side of a comparison is only ever read as a property reference.
Title == salt throws unless Salt is a real, resolvable property.
- Throw a
ParsingException when an unquoted word is not a recognized property and not a recognized literal (true, false, null, a number, a date, a guid). This keeps unquoted booleans and numbers working, and closes only the ambiguous string case.
Either option is a breaking change, because it turns some filters that parse today into a thrown exception. This is why it targets the next major version rather than a patch.
Context
This came out of a security and correctness review of the filter parser. Commit 3605423 already corrected the opposite side of this ambiguity, for a quoted string value that matches a property name.
Summary
Title == saltdoes not throw today. QueryKit reads the unquoted wordsaltas the literal textsalt, the same asTitle == "salt". This is inconsistent with the README, which said this throws aParsingException(corrected in a separate PR).The risk
The parser already treats an unquoted word as a possible property reference on the right side of a comparison, for example
Rating > Author.Score. An unquoted string value uses the same grammar position. If a consumer later adds a property namedSaltto their entity, the exact same filter textTitle == saltsilently changes meaning, from a literal string comparison to a property-to-property comparison. No exception, no warning.Proposed options for the next major version
Pick one:
Title == saltthrows unlessSaltis a real, resolvable property.ParsingExceptionwhen an unquoted word is not a recognized property and not a recognized literal (true,false,null, a number, a date, a guid). This keeps unquoted booleans and numbers working, and closes only the ambiguous string case.Either option is a breaking change, because it turns some filters that parse today into a thrown exception. This is why it targets the next major version rather than a patch.
Context
This came out of a security and correctness review of the filter parser. Commit
3605423already corrected the opposite side of this ambiguity, for a quoted string value that matches a property name.