[SERVER-55509] {example: /regex/} and {example: {$eq: /regex/}} do not mean the same thing Created: 24/Mar/21  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Query Language
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Charlie Swanson Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-55639 $in with regex has special meaning Backlog
is related to SERVER-10840 injection is too easy with agg framew... Backlog
is related to SERVER-34012 Planner's logic for taking union of i... Closed
Assigned Teams:
Query Optimization
Operating System: ALL
Participants:

 Description   

Adding a $eq should not have an impact on the meaning of the query, and generally it does not. {a: 4} is the same query as {a: {$eq: 4}}. Regexes are the exception to this, where {a: /regex/} will match either a stored regex type which is identical or a string which matches the regex. {a: {$eq: /regex/}} will only match stored regexes. This makes it harder to generally reason about the language. It makes it harder to write generic query analysis, parsing, or transformations - leading to special cases such as this one in $lookup

This also complicates recommendations for avoiding "MQL injections" by adding an explicit $eq to your application's generated queries. An "MQL injection" might happen if your application issues a query {field: <value selected by user>} and a malicious user inputs a value like {$gt: 4} instead of an expected constant. Using an explicit $eq would prevent the user from being able to change the query.



 Comments   
Comment by Ethan Zhang (Inactive) [ 25/Mar/21 ]

The documentation of the use of regex seems to be a little bit unclear, I actually did not see the behavior mentioned in this ticket documented, maybe I missed it somewhere or we should clarify in the documentation?

Generated at Thu Feb 08 05:36:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.