Skip to content
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

Avoid using deprecated Buffer API on newer Node.js #67

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ChALkeR
Copy link

@ChALkeR ChALkeR commented Mar 2, 2018

This avoids using Buffer constructor API on newer Node.js versions.

To achieve that, Buffer.from presence is checked, with validation that it's not the same method as Uint8Array.from.

Also an additional type-guard is added in the fallback code path to ensure that typed numbers are never accidently fed into new Buffer input.

Given this module popularity and the fact that old Buffer constructor API was used in a single place, I decided to just feature-detect it in-place instead of pulling in polyfill deps.
Another way would be to just use Buffer.from and do var Buffer = require('safe-buffer');

Refs:
https://nodejs.org/api/deprecations.html#deprecations_dep0005_buffer_constructor
Tracking:
nodejs/node#19079

This avoids using Buffer constructor API on newer Node.js versions.

To achieve that, Buffer.from presence is checked, with validation that it's
not the same method as Uint8Array.from.

Also an additional type-guard is added in the fallback code path to ensure
that typed numbers are never accidently fed into `new Buffer` input.

Refs:
https://nodejs.org/api/deprecations.html#deprecations_dep0005_buffer_constructor
@ChALkeR
Copy link
Author

ChALkeR commented Jul 27, 2018

Ping?

signatureBuffer = Buffer.from(signatureBase64, 'base64');
} else {
// Node.js <4.5.0 || >=5.0.0 <5.10.0
if (typeof signatureBase64 === 'number') {
Copy link

@jacobq jacobq Aug 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to guard against invalid input, wouldn't it make more sense move this check higher? Perhaps it should also be formulated as an assert since that's what's being done elsewhere in this code e.g.

// ...
var signatureBase64 = parsedSignature.params.signature;
assert.string(signatureBase64, 'signatureBase64');
var signatureBuffer;
// ...

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assertion is made by Buffer.from internally. Although I agree assert.string can be used for the fallback rather than the type checking.

A TypeError will be thrown if string is not a string.

Source: https://nodejs.org/docs/latest-v10.x/api/buffer.html#buffer_class_method_buffer_from_string_encoding

Copy link

@jacobq jacobq Aug 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, so, IIUC, the rationale for pushing the check down into the fall-back code is that it makes it more obvious that it can be removed when the fall-back code is removed. I guess that makes sense. It just seemed a little odd to me that there are ~10 lines of code just to use Buffer.from if it's available...maybe I'm naïve, but it seems like it ought to be a one-liner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants