New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

instanceof failing in window / iframe contexts #350

Merged
merged 3 commits into from Sep 5, 2016

Conversation

Projects
None yet
2 participants
@ddxdental
Contributor

ddxdental commented Sep 2, 2016

prepareContent fails to properly derive type of data passed in, should the Blob originate from another context (window or iframe).

Described here from MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof)

instanceof and multiple context (e.g. frames or windows)

Different scope have different execution environments. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results. For instance, [] instanceof window.frames[0].Array will return false, because Array.prototype !== window.frames[0].Array and arrays inherit from the former. This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue. For instance, you can securely check if a given object is in fact an Array using Array.isArray(myObj)

Proposal is to first check instanceof (much faster), with a backup check against Object.prototype.toString which is safe across contexts (http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/)

ddxdental added some commits Sep 2, 2016

instanceof failing in window / iframe contexts
instanceof fails with data passed in from other contexts
Merge pull request #1 from ddxdental/ddxdental-instanceof-contexts
instanceof failing in window / iframe contexts
Show outdated Hide outdated lib/utils.js
@dduponchel

This comment has been minimized.

Show comment
Hide comment
@dduponchel

dduponchel Sep 5, 2016

Collaborator

I think you forgot to actually use isBlob :-)

Collaborator

dduponchel commented Sep 5, 2016

I think you forgot to actually use isBlob :-)

@ddxdental

This comment has been minimized.

Show comment
Hide comment
@ddxdental

ddxdental Sep 5, 2016

Contributor

Wow. Well that was dumb ;) Upped

Contributor

ddxdental commented Sep 5, 2016

Wow. Well that was dumb ;) Upped

@dduponchel dduponchel merged commit 887dcd8 into Stuk:master Sep 5, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

dduponchel added a commit to dduponchel/jszip that referenced this pull request Sep 28, 2016

Fix test and test error reporting.
The pull request #350 introduced a bug but the automated tests didn't
catch it:

> ReferenceError: Blob is not defined
>     at /home/travis/build/Stuk/jszip/lib/utils.js:425:38
>     at Array.1 (/home/travis/build/Stuk/jszip/node_modules/lie/lib/index.js:88:21)
>     at nextTick (/home/travis/build/Stuk/jszip/node_modules/lie/node_modules/immediate/lib/index.js:61:18)
>     at process._tickCallback (node.js:458:13)
>
> The command "npm run $COMMAND" exited with 0.
>
> Done. Your build exited with 0.

This commit fixes:
- the bug: check if Blobs are supported before actually using them
- the build: if an uncaught error/rejection happens, exit with a non
  zero code.

@dduponchel dduponchel referenced this pull request Oct 5, 2016

Merged

Release v3.1.3 #365

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment