[SERVER-40354] mongocryptd should echo back all fields in command, and none that aren't Created: 27/Mar/19 Updated: 29/Oct/23 Resolved: 06/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.11 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jeffrey Yemin | Assignee: | Ted Tuckman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Query 2019-05-06, Query 2019-05-20 | ||||||||
| Participants: | |||||||||
| Description |
|
mongodcryptd should respect whatever fields the caller passes to it, and echo them back unchanged (except for jsonSchema field and the markings, of course), and should not add any additional fields. This gives drivers the most flexibility in terms of the design space for implementation of FLE. Some drivers may be invoking mongocryptd at a layer above where $db and other common fields are added, and some below. By echoing back what the driver provides, it will allow either design to work seamlessly. Current behavior:
Expected behavior:
|
| Comments |
| Comment by Githook User [ 06/May/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Ted Tuckman', 'username': 'TedTuckman', 'email': 'ted.tuckman@mongodb.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ted Tuckman [ 24/Apr/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Wound up doing this by looking at the original command and removing all fields from the response that were not in the original just before it gets sent back to the drivers. This should work for all the fields discussed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 24/Apr/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'email': 'ted.tuckman@mongodb.com', 'name': 'Ted Tuckman', 'username': 'TedTuckman'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Benvenuto [ 28/Mar/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Here is the logic of what gets echoed back in the result field for a command in mongocryptd:
Other notes
For rule 1, insert/update/delete/distinct (IDL based commands) will always echo back values with default values set even if they were not sent by the client. This is the way the generated serializers work for these operations. For find/findAndModify/count/etc, I cannot speak to them. Changing this IDL behavior is difficult. If we needed to change it, they can be stripped at the cost of a new pass to strip fields that were not in the input before returning them to the client. For rule 2, I thought it would be easiest to echo the fields back to the client that were sent to the client. This behavior can easily be changed (with the possible exception of $db in some cases).
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Craig Homa [ 28/Mar/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The Query team will need to discuss this further with the Drivers teams prior to implementing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 27/Mar/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Proposal:
CC kevin.albertson, matt.broadstone@mongodb.com, mark.benvenuto@mongodb.com | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 27/Mar/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Here's what the POC driver is actually sending:
and here's what mongocryptd is returning:
mark.benvenuto@mongodb.com can you explain the algorithm for the generation of fields in the result document? I can understand why it's echoing $db and $readPreference, but why bypassDocumentValidation? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 27/Mar/19 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thought about this a bit more:
|