You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using bcryptjs 0.7.10, we are experiencing troubles using .hash() and .compare() on the Raspberry Pi.
Specifically, the operation crashes with a RangeError: Maximum call stack size exceeded error, but before it does that, it churns for about 2 minutes, and then outputs 100+ of these:
(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.
Of note: Ghost has run into this issue as well (they ran into it 4 months ago when they switched from bcrypt-nodejs to bcryptjs), but they don't exhibit the same errors, the hashing/comparing process just takes a really long time.
In both cases, a simple npm i bcrypt followed by replacing all instances of require('bcryptjs'); with require('bcrypt'); is an acceptable workaround, although people are left wondering why a pure JS implementation of bcrypt would take several orders of magnitude longer to hash or compare a password than a native implementation.
The text was updated successfully, but these errors were encountered:
I have changed the asynchronous behaviour to use setImmediate if available. Regarding computation time this is either related to the low level implementation used, which is not mine, or, more likely, a thing that JavaScript simply isn't nearly as good at as native code.
Using bcryptjs 0.7.10, we are experiencing troubles using
.hash()
and.compare()
on the Raspberry Pi.Specifically, the operation crashes with a
RangeError: Maximum call stack size exceeded
error, but before it does that, it churns for about 2 minutes, and then outputs 100+ of these:Of note: Ghost has run into this issue as well (they ran into it 4 months ago when they switched from bcrypt-nodejs to bcryptjs), but they don't exhibit the same errors, the hashing/comparing process just takes a really long time.
In both cases, a simple
npm i bcrypt
followed by replacing all instances ofrequire('bcryptjs');
withrequire('bcrypt');
is an acceptable workaround, although people are left wondering why a pure JS implementation of bcrypt would take several orders of magnitude longer to hash or compare a password than a native implementation.The text was updated successfully, but these errors were encountered: