fix: keep attributes whose name starts with an underscore - #314
Conversation
taoqf
left a comment
There was a problem hiding this comment.
-
attributes starting with an underscore
keeps the leading underscore in the attribute name:
TypeError: Cannot read properties of undefined (reading 'should')
at Context. (test/tests/issues/206.js:8:27)
at process.processImmediate (node:internal/timers:504:21) -
attributes starting with an underscore
supports the hyperscript "_" attribute:
TypeError: Cannot read properties of undefined (reading 'should')
at Context. (test/tests/issues/206.js:15:27)
at process.processImmediate (node:internal/timers:504:21)
|
Same here — rebuilding |
The attribute-name regex disallowed a leading underscore, so names such
as Angular's _ngcontent-* / _nghost-* and hyperscript's _ were parsed
with the underscore stripped (getAttribute('_foo') returned undefined).
This was originally excluded to avoid a __proto__ prototype-pollution
vector (taoqf#129). Allow the leading underscore and instead reject the
literal __proto__ key explicitly, as suggested in taoqf#129, which keeps the
pollution guard while fixing taoqf#206. Values are strings, so no other key
can reach Object.prototype.
d472809 to
3aff8be
Compare
|
Rebased onto |
Attribute names beginning with an underscore are dropped, because the attribute regex's first-character class omits
_:_ngcontent-…becomesngcontent-…and Hyperscript's_attribute is lost._was excluded to avoid__proto__prototype pollution (#129); allow_and reject only__proto__explicitly, as suggested on #206. Attribute values are always strings, soobj['__proto__'] = <string>is a no-op and the pollution guarantees are kept (the #129 test is updated to assert them directly). Closes #206.