feat: Ensure password inputs are always masked#78
Conversation
billyvg
left a comment
There was a problem hiding this comment.
Is this something we'd want to upstream? If so it should probably an option, though we could start an issue since 2.0 would be a good place to make that breaking change.
The password -> text is a good candidate to upstream though 👍
| // Change type to text (simulate "show password") | ||
| await page.click('#show-password'); | ||
| await page.type('#password', 'XY'); | ||
| await page.click('#show-password'); |
There was a problem hiding this comment.
This toggles it back to type: password? It might be better to test leaving it as text
There was a problem hiding this comment.
We test before this line (on 512) that it works while being a text field, so I think this should be OK?
Lms24
left a comment
There was a problem hiding this comment.
Nice, thanks for addressing this!
Yeah, I think the type change stuff makes sense to upstream. Not sure if they would like to have the "do not allow to opt-out of password" stuff upstream, but I guess I can also just ask! |
|
Added upstream PR: rrweb-io#1170 |
This PR does two things:
type="password"inputstype=passwordand have this type changed (so e.g. through a "show password" toggle) always keep the password masked, even afterwards.We should never record passwords, and e.g.
toggle passwordtype buttons are quite common and would easily leak the password into the replay as of now.We do this by adding a
rr_is_passwordattribute to the HTML input when the type is changed frompasswordto something else. This is IMHO the easiest solution for this, and since we only add this when the type is really changed (so not eagerly for all inputs) IMHO it's an acceptable tradeoff to have this in the DOM.Closes #34