TheFriendlyCoder
commented
6 months ago Something that might be even more versatile would be if you allowed the logic for the masking / censoring operation to be defined by a callback function / closure. If the callback was provided some useful contextual information like the key-value being parsed and a reference to where the context is in the JSON parse tree, you could do all sorts of fancy stuff. This would be overkill for my current needs, but might be worth thinking about.
I have a need to customize the censor string used for different JSON fields depending on the context. This is needed so that code that parses JSON data replayed from cassettes works properly. Consider, for example, a masked out UUID field. Deserialization of that field may require the value to be a valid UUID, but if it is replaced by a standard string like "*****", the deserialization process will fail ... but only when replaying data from the cassette. Generation of the cassette will work fine, which makes this problem somewhat hard to notice right away.
Further, the exact form of masking may need to be different depending on the context. So for example, you may want to mask a UUID field with a random UUID, but you may need an integer or floating point value to be masked by some fake data that suits that particular data type.