fix: Use a null prototype object for this.files #766
Conversation
This approach is taken to prevent overriding object methods that would
exist on a normal object Object.create({})
| @@ -179,16 +179,16 @@ var out = { | |||
| */ | |||
| forEach: function(cb) { | |||
| var filename, relativePath, file; | |||
| /* jshint ignore:start */ | |||
| // ignore warning about unwanted properties because this.files is a null prototype object | |||
| for (filename in this.files) { | |||
There was a problem hiding this comment.
@Stuk we could use for(filename of Object.keys(this.files)) { here instead, but it seems jszip is targetting es3 in jshintrc.
We could set this to es6 but I assume this would break for a number of users and you would want to avoid that?
This is the error that comes up if I change it:
./lib/object.js
182 | for (filename of Object.keys(this.files)) {
^ 'for of' is available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz).
There was a problem hiding this comment.
Yeah, there's a bigger task for upgrading the tooling and browser compatibility for this library. The approach here looks good.
| @@ -179,16 +179,16 @@ var out = { | |||
| */ | |||
| forEach: function(cb) { | |||
| var filename, relativePath, file; | |||
| /* jshint ignore:start */ | |||
| // ignore warning about unwanted properties because this.files is a null prototype object | |||
| for (filename in this.files) { | |||
There was a problem hiding this comment.
Yeah, there's a bigger task for upgrading the tooling and browser compatibility for this library. The approach here looks good.
| assert.equal(result, "hello\n", "the zip was correctly read."); | ||
| done(); | ||
| })['catch'](JSZipTestUtils.assertNoError); | ||
| }); |
There was a problem hiding this comment.
I tried removing the Object.create(null) fix, to see if this test failed and it didn't, so I don't think this is actually catching the issue?
There was a problem hiding this comment.
That's a good point - but I'm not entirely sure how to test this change because essentially this change is about making sure toString / __proto__ / __constructor__ etc are not available in the first place.
I guess I could add a test that shows that toString raises an error - but I'm not sure how useful that would be in the long run?
The reasoning for this test specifically was to show that files with names that shadow standard Object method names can still be accessed correctly
|
@Stuk it seems like the build pipeline is failing. But from what I can tell this is an existing failure that is unrelated to this change? |
|
@Stuk polite reminder about this :) There's no real rush though so take your time |
|
@MichaelAquilina I've updated the test to confirm the prototype isn't modified. Mind double checking that change? Then I think this is good to go! |
Backport Stuk#766 to v2.6.1
This approach is taken to prevent overriding object methods that would exist on a normal object Object.create({})