[SERVER-12459] Add a way to recursively obfuscate data instead of stripping it altogether Created: 23/Jan/14  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Aggregation Framework, Querying, Security
Affects Version/s: 2.5.4
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Buzz Moschetti Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Query Execution
Backwards Compatibility: Minor Change
Participants:

 Description   

Currently $redact is more like ... um.... $remove. When conditions are true, it strips all the content away; there's not even a trace that it existed, which is slightly different than redact.

A very useful variation of this would implement the following actions to replace info instead of stripping it away:
$$VALUE: A specific value
$$LOREM: Give a certain keyword arg (SSN, phone, address, email), produce a random but construct-appropriate value). VERY important for testing where the value has to bubble up to the business logic in a form that doesn't blow up the business logic.
$$RANDOM: A totally random value appropriate for the type
$$HASH: A salted hash representation of the content, guaranteed to produce the same digest for the same field value. This is very important for consumers who need to test with "concealed" data but in pulling it into their code logic, need to keep the proper distribution of values. The salt is scoped to the collection. As long as at least ONE record is in the collection, the salt lives for that collection.



 Comments   
Comment by Asya Kamsky [ 23/Nov/17 ]

when it's known where these fields are in the structure of the document, $addFields can probably suffice for several of these examples.

Generated at Thu Feb 08 03:28:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.