[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: |
|
||||||||||||||||
| 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? |