We actually only use sanitizeInput when validation fails, so it's important that it works in this case.
See context here.
Details
Details
I added a test case to validation-utils.test.js that was failing before the changes in this diff
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
I think this solution has an issue: some sensitive data could be placed in a prop that fails the validation and we probably won't be able to sanitize it properly. I don't think this problem can be solved in general, but maybe we should traverse the whole tree after the conversion and redact by hand all the fields that should usually be sanitized e.g. password.
Comment Actions
Hmm... perhaps I'm not understanding you correctly. I added a couple test cases with nested validators, and these did reveal an issue: I wasn't propagating options during recursion. But a second traversal (as you suggested) didn't appear to be necessary.
Perhaps you are suggesting that we should redact properties based on their keys? That's probably not a bad idea, but I'd rather keep it out of the scope here for now.
The way it's written now, if an unrelated part of the input fails validation, passwords in an expected position should still be redacted. It's only if the password itself is in an unexpected position that we would fail to redact it.
Comment Actions
Hmm... perhaps I'm not understanding you correctly. I added a couple test cases with nested validators, and these did reveal an issue: I wasn't propagating options during recursion. But a second traversal (as you suggested) didn't appear to be necessary.
Perhaps you are suggesting that we should redact properties based on their keys? That's probably not a bad idea, but I'd rather keep it out of the scope here for now.
Yeah, that's my suggestion. And agree, we don't have to include this in the scope right now.
The way it's written now, if an unrelated part of the input fails validation, passwords in an expected position should still be redacted. It's only if the password itself is in an unexpected position that we would fail to redact it.
I was thinking also about cases like this:
const validator = tShape<{
+nested1: { +password: string },
}>({
nested1: tShape<{ +password: string }>({
password: tPassword,
}),
});
const object = { nested2: { password: 'password' } };Where we won't redact the password. So basically, any misplacement between the sensitive prop and the root would block us from sanitizing it.