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.
In https://github.com/status-im/embark-area-51/commit/62964c8ce we've introduced a
regression where are two errors are thrown when `Layout` component is rendered:
- one for NavItem not having a key property
- one for margin-top not being a supported style property on Container
This commits fixes both.
Cockpit allows for authentication via a `token` query parameter a la
```
http://localhost:8000/embark?token=xxxx-xxxx-xxxx-xxxx
```
So far, this was the only query parameter cockpit knew about, which is
why the algorithm during bootstrap always assumed that, if we have
query parameters, there has to be a `token` query parameter.
However, since 20831179fc, this turns out to be a problem. The hashing algorithm
for the request headers will throw, when `token` is not defined, which
can be possible with future features that add new query parameters.
This can be easily reproduced by bootstrapping/refreshing Cockpit using
any arbitrary query string parameter that is not `token`.
With this commit we ensure that we only perform query string authentication
when a `token` parameter is available.
Prior to this commit it wasn't possible to authenticate using the
`token` query param as the `host` used for authentication doesn't
match the one of the Embark host.
This commit adds a new component to decode and analyze transactions.
It's similar to the transaction component that's already available,
with the difference that it takes advantage of the ReactJson tree
view for better analysis experience.
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.