Default behavior of logging to file is no longer needed now that Embark log history can be properly served using the `ProcessLogsApi` and `LogHandler` classes.
# Conflicts:
# lib/core/logger.js
# lib/modules/blockchain_process/blockchain.js
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
When running `embark blockchain` followed by `embark run` previously, logs generated in the standalone `embark blockchain` process were black boxed and not accessible to the main Embark process.
This is fixed by creating a client IPC connection in the `embark blockchain` process that connects to the IPC server connection running in `embark run`. The connection is made by way of polling `ipc.connect` and continues polling even after a connection is made in case `embark run` is killed and restarted without restarting `embark blockchain`.
`LogHandler` was introduced to extrapolate functionality used in `ProcessLauncher` that needed to also be used in the standalone blockchain process. It also caps the number of logs that are stored in memory per process by a constant value defined in `constants.json`.
A `blockchain_listener` was module was created (and run inside of `embark run`) that listens for logs emitted by the `embark blockchain` client IPC and runs them through the `LogHandler`. Additionally, this module registers the API endpoints needed to handle requests for blockchain process logs in the cockpit (which were 404’ing before).
# Conflicts:
# lib/modules/blockchain_process/blockchain.js
display last line on tx
fix debugger call
listen to source event only after jumping to the end
keep track of last tx; add minimal debug feature; fix ast issue
initial debugger apis & ui integration
prevent crash when step is out of bounds; send all all available data in websocket
add debugger commands
fix line number tracking in editor; toggle breakpoints
replace timeouts with callbacks
add debugger manager & refactor
refactor debugger api
refactor cmd line debugger
reduce debugger decoupling
reduce debugger decoupling
fix debug buttons
trigger source update so api triggers ws event to update source location
move locals and contracts vars to a json view
improve debugger icons
simplify debugger data
update debug package
add command handler to get a contract given a tx; update debugger so it can get a contract by its tx instead of tracking latest txs only
update debugger package
Data send from the client with GET parameters are serialized in the
request body's `params` property. As express doesn't seem to parse
those, we have to do it manually to perform object property traversals.
The authenticators request hash algorithm produced different hashes than
on the client, because client-side hash-request don't include the query
parameters of a URL.
This causes authentication issues when sending any requests with query
parameters. This commit ensures we ignore them on the server as well.
As it turns out, a websocket request doesn't contain some of the
hashable properties in order to be validated. Because of that, we'll
still use tokens here until we find a better way to do it.
Instead, we want to hash a header to sign a request with a client nonce,
http method and URL. This is a first step towards protecting the backend
against eavesdropping.
Please note that this will still be susceptible to replay attacks.
