All code to be run in the console is run through a completely sandboxed VM2 instance, instead of the default Node VM.
VM2 will only allow whitelisted packages in a `require` statement. The whitelisted packages needed to run EmbarkJS scripts are:
```
[
"@babel/runtime-corejs2/helpers/interopRequireDefault",
"@babel/runtime-corejs2/core-js/json/stringify",
"@babel/runtime-corejs2/core-js/promise",
"@babel/runtime-corejs2/core-js/object/assign",
"eth-ens-namehash"
]
```
This can be circumvented in an Embark context (ie Plugin) if needed, for example in a Plugin constructor:
```
Embark.events.emit('runcode:register', 'require', require('lodash'), false);
Embark.events.request("runcode:eval", "_.head(['a', 'b', 'c', 'd']);", (err, result) => {
if(err) return console.log('========> error: ' + err);
console.log('========> ' + result);
});
```
Will emit `========> a`.
NOTE: Attempts to use this method to override `require` and `eval` should be handled by Embark and not allowed.
NOTE: VM2 seems to allow `eval`, however it is in a completely sandboxed environment, so I'm unsure that we need to be too concerned with this. Thoughts?
Refactor tests to use standalone instance of the newly created VM class, so that code is not evaluated through the console. This was done based on the new unit test case where accounts are redefined in a subsequent unit test, which was not originally working with the initial VM2 PR.
Refactor `codeRunner`, put all code-affecting logic in the `VM` class.
Changed `runCode` to `VM` and converted to TypeScript
Add unit tests for `VM`.
Check if IPFS config has `API.HTTPHeaders.Access-Control-Allow-Origin` before attempting to update it.
`ipfs init` produces a default configuration without a `API.HTTPHeaders.Access-Control-Allow-Origin` element in the JSON. This caused an error to be thrown when attempting to update the IPFS config to provide CORS values.
Regular transactions (aka “dev funds”) exist in embark as a workaround to a known bug in geth when using metamask. The workaround is to send a transaction at a regular interval (1.5s), which pushes through any transactions that were stuck. The problem is that the transaction logs and trace logs become cluttered and difficult to parse visually.
This PR disables regular transactions until the following conditions are met:
1. Embark is running geth
2. The user is running metamask in their browser
3. The user authenticates to the cockpit with `enableRegularTxs=1|true` in the query string.
A console warning is show in large letters in the browser with a link to the cockpit URL that includes the special query string to enable regular txs.
This could be extended later to have a button in the cockpit that start/stops regular txs. Or at least extended to allow disabling of regular txs once started.
Support standalone blockchain process.
Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei.
The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward.
There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts.
JSON.stringify unknown log messages
Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config.
Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation.
In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration.
This commit does two things:
1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration
2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
Send a message over IPC when a command is executed from the REPL so that
command history is immediately unified across `embark run` and one/more `embark
console`. Previously, for `embark console` to pick up a command entered in the
REPL of an `embark run` of which it was an IPC client it would have to be
restarted, and vice versa.
I had to eject the webpack config and add this to get any project at all to run on Windows/Git Bash without this error:
Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema. ││ - configuration.context: The provided value "C:/Users/xxx/GitHub/xxxxxx" is not an absolute path! ││ -> The base directory (absolute path!) for resolving the `entry` option. If `output.pathinfo` is set, the included pathinfo is shortened to this directory.
Not sure if this is the best place, but should work on any platform.
Context (Environment)
OS: Windows 10, Git Bash v2.20.0 64bit
Embark Version: 3.2.7
Node Version: 10.14.2
NPM Version: 6.4.1
Parse legacy version of Parity. Pre-version 2 of Parity outputs “Parity <version>” instead of the post-version 2 “Parity-Ethereum”. Embark was emitting an error when the version of an older Parity client could not be parsed, and no warning messages regarding the version were shown.
This PR modifies the regex that parses the version so that older versions of Parity can be detected and the appropriate warning message can appear.
This PR replaces #1202.
When embark is running on Linux and macOS, unix socket files are used for
geth's and embark's IPC files. A problem can arise if a DApp is in a deeply
nested directory structure such that character-length of the path to a socket
file exceeds the maximum supported length. See #450.
Also, if the DApp context is a Linux container running on a Windows Docker
host, and if the DApp is mounted from the host's file system, there is a
problem: unix socket files are incompatible with the Windows file system.
Solve both problems at once by storing a DApp's `.ipc` files in a directory
within `os.tmpdir()`. Introduce `ipcPath()` in `core/fs.js` and use a truncated
SHA-512 hash of the DApp's path in the name of the temporary directory created
for that purpose so that DApps won't collide (with an acceptably low
probability of collision).
Start the `embark run` dashboard after services have been started so the REPL
instantiated by the dashboard can successfully request the `console:history`
event.
Delete `cmd/dashboard/command_history.js` since it's no longer in use.
Changes in c64c093a48 resulted in a regression
that ENS functions within console/dashboard didn't work properly anymore.
This commit ensures that both APIs, `EmbarkJS.Names.resolve()` as well as
`EmbarkJS.Names.lookup()` can be either used using `async/await` or promised
based syntax within the console/dashboard.
Example:
```
await EmbarkJS.Names.resolve('me.eth.eth');
EmbarkJS.Names.resolve('me.eth.eth').then(val => ..., err => ...)
EmbarkJS.Names.resolve('me.eth.eth', (err, val) => ...)
```
Same with:
```
await EmbarkJS.Names.lookup('0x...');
EmbarkJS.Names.lookup('0x...').then(val => ..., err => ...)
EmbarkJS.Names.lookup('0x...', (err, val) => ...)
```
Anthony Laibe
emizzle
Jonathan Rainville
Iuri Matias
Michael Bradley, Jr
Wil Bown
Andre Medeiros
Pascal Precht