Summary:
Changelog: Fix server certificates not being generated for first time users.
As reported in https://fb.workplace.com/groups/flippersupport/permalink/1247554795725176/, server certificates are not generated properly for new users.
Also the fix. Omg. How does typechecking not find this?
...Oh yeah yeah I now, `await not-a-promise` is juuuusst fine. Long live `.then(` I guess...
Reviewed By: jknoxville
Differential Revision: D32203132
fbshipit-source-id: abd75c178e9c8640a266b2012b9250503d4258be
Summary:
Workaround for idb weirdness
Originally started at D27590885
Re-appared at https://github.com/facebook/flipper/issues/3009
Reviewed By: mweststrate
Differential Revision: D32106952
fbshipit-source-id: 63d4fa64503c5c2ba80dae113850c937450ab0fb
Summary:
This was the last eslint warning for `flipper-server-core` and the only call-site
was async already.
Reviewed By: mweststrate
Differential Revision: D32026626
fbshipit-source-id: 0d6f06086c33707b26f58f668ad533daca9de7dd
Summary: Fixed several tests that caused uncaught promise rejects to fire after the tests finished. This caused jest to fail if there are too many of them.
Reviewed By: aigoncharov
Differential Revision: D32118124
fbshipit-source-id: 50734dab6dee2efec7f056940af72858b27b1707
Summary: Create an example of how one can use `js-flipper` in a browser to connect to Flipper over WS.
Reviewed By: mweststrate
Differential Revision: D31688114
fbshipit-source-id: 135f826daeddeda8dca5b3df6504cc2bdc04dd1b
Summary:
Standardize WS implementation for JS environments.
Why do we need a separate server implementation for browsers?
Browser targets cannot authenticate via the default certificate exchange flow. For browser targets we verify the origin instead.
Moreover, for already forgotten reasons the initial implementation of the WS server for browsers used a different kind of message structure and added extra `connect`/`disconnect` messages. After examination, it seems the `connect`/`disconnect` flow is redundant.
Major changes:
1. Updated class hierarchy for WS server implementations.
2. Updated browser WS server to support the modern and the legacy protocols.
3. Now a websocket connection with the device is closed on error. The idea is it is highly unlikely to handle any subsequent messages properly once we observe an error. It is better to bail and reconnect. What do you think?
Reviewed By: mweststrate
Differential Revision: D31532172
fbshipit-source-id: f86aa63a40efe4d5263353cc124fac8c63b80e45
Summary: moved `app/src/server` to `flipper-server-core/src` and fixed any fallout from that (aka integration points I missed on the preparing diffs).
Reviewed By: passy
Differential Revision: D31541378
fbshipit-source-id: 8a7e0169ebefa515781f6e5e0f7b926415d4b7e9
