feature/invert client + providers to constructor params w/ specific interface

[mateodelnorte]

• refactoring rest client to composition instead of inheritance
• refactoring network providers be provided via constructor, allowing any number of providers
  • refactor this.providers to array
  • refactor all providers to match common interface
  • refactor connect() to cycle through all specified providers
• refactor crypto usage to constructor-provided param
• refactor appSecret to be provided by env vars to both tests/sdk and services

[alex-miller-0]

I think we should remove the crypto.randomBytes fallback for the privKey generation and instead require the user to provider a private key hex string. crypto does not work with react native, which will require the user to generate bytes with something like this

[mateodelnorte]

Can do

[mateodelnorte]

Looks like there are 5 places where crypto is used:

gridplus-sdk/src/rest/client.js

Line 41 in 7ca6294

const hash = crypto.createHash('sha256').update(preImage).digest();

gridplus-sdk/src/rest/client.js

Line 103 in 7ca6294

const msg = crypto.createHash('sha256').update(`${id}${type}${req}`).digest();

gridplus-sdk/src/rest/client.js

Line 130 in 7ca6294

this.appSecret = crypto.randomBytes(6).toString('hex');

gridplus-sdk/src/rest/client.js

Line 137 in 7ca6294

return crypto.randomBytes(32).toString('hex');

gridplus-sdk/src/rest/client.js

Line 139 in 7ca6294

return crypto.createHash('sha256').update(this.sharedSecret).digest().toString('hex');

Those uses consolidate to

crypto.createHash('sha256').update(x).digest(); and crypto.randomBytes(x).toString('hex');.

We could pass in a cryptoProvider imp via the SDKClient constructor, which it will pass into the RestClient. We could provide implementations that will work for node, web, and react-native. Users would just specify which to use in the constructor. The imps would be pretty simple:

export const node {
  createHash: (input) => { return crypto.createHash('sha256').update(input).digest(); },
  randomBytes: (num) => { return crypto.randomBytes(num).toString('hex'); },
}

Usage could be something like...

import { Client, crypto } from 'gridplus-sdk';
new Client({ crypto: crypto.node, ... })

[mateodelnorte]

Took a swack at that, in commit 5355edc above.

[alex-miller-0]

Looks great. There are several crypto libs for RN so we can just swap those in depending on the build.

Also I've had problems with elliptic in RN before. Don't think there's an action item here but we should just be aware of it.

Edit: looks like there may be a workaround within elliptic. I'll make an issue to ensure all elliptic functionality here works with RN

[mateodelnorte]

Sounds good. Last refactor left on this is encapsulating the providers to conform to a specific interface and moving them to be passed in through the constructor. I should be able to get it done after the SmartGrid meeting.

[alex-miller-0]

Two things that need to be updated in this API (whether in this PR or not):

1. connect should take a serial argument (so that it can find a specific agent to connect with)
2. pair should take a appSecret argument. I think this is more natural behavior than generating an app secret via the SDK and then calling pair. I think we can have it as an optional argument, but I do think many devs will want to generate their own secrets rather than relying on our mechanism.

[mateodelnorte]

@alex-miller-0 shouldn't we be using a means other than crypto to provide entropy to crypto/react-native?

[alex-miller-0]

The origin of the entropy is irrelevant for cryptographic purposes. A RN app would use a different source, but I don't see any reason not to use crypto (which is simpler) in a test that will run via node