Summary:
Changelog: Initiate cert exchange when medium changes
Fixes the following bug:
1. Start an iOS app with WWW cert exchange
2. Get cert (and fake serial of a virtual device)
3. Close app
4. Restart Flipper
5. Switch app to FS_ACCESS cert exchange
6. Start app
Expected result:
App re-initializes cert exchange to get a new serial of a real device
Current result:
App tries to connect securely using the previous fake serial of a virtual device. Flipper does not recognize it and refuses the connection.
Reviewed By: lblasa
Differential Revision: D33163798
fbshipit-source-id: 67126a9b562f2cb7cfe6521a46abf38b2699fb2d
Summary:
This change moves the existing serialiser from FlipperWebSocket to FlipperURLSerializer.
The serialiser can be shared with Android as it no longer has any iOS dependencies.
Reviewed By: fabiomassimo
Differential Revision: D31571272
fbshipit-source-id: 0769b384d4143d7404fcfcf993d49dc1b00eeffd
Summary: This change adds a function to base64 encode. It is used to encode the CSR which gets added to the connection url.
Reviewed By: passy
Differential Revision: D31570706
fbshipit-source-id: 8356550fe87ae3ac6aae8616744a9339cf69b511
Summary:
This change makes WebSockets the default for Flipper on iOS.
Having said that, we are introducing some logic to deal with clients connecting to older Flipper Desktop versions.
The mobile client will first attempt to connect via WebSocket with the Desktop. This connection can either be secure or insecure. If that fails, it will attempt to connect via RSocket.
Connection failure logic:
The mobile client will attempt to connect up-to 3 times via a WebSocket. If it fails to connect, then the socket provider is switched to RSocket.
As before, the mobile client will attempt to connect up-to 3 times via a RSocket. If it fails to connect, then the socket provider is switched back to WebSocket.
Process repeats until a successful connection is established.
Some logs that can be seen from iOS:
2021-09-15 14:31:51.193503+0100 Sample[92026:92107440] [] nw_protocol_get_quic_image_block_invoke dlopen libquic failed
2021-09-15 14:31:51.878257+0100 Sample[92026:92107440] [connection] nw_socket_handle_socket_event [C1.1:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:52.553729+0100 Sample[92026:92107440] [connection] nw_socket_handle_socket_event [C1.2:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:52.899511+0100 Sample[92026:92107442] [connection] nw_connection_get_connected_socket [C1] Client called nw_connection_get_connected_socket on unconnected nw_connection
2021-09-15 14:31:52.899664+0100 Sample[92026:92107442] TCP Conn 0x600001d384d0 Failed : error 0:61 [61]
2021-09-15 14:31:57.120120+0100 Sample[92026:92107439] [connection] nw_socket_handle_socket_event [C2.1:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:57.141785+0100 Sample[92026:92107439] [connection] nw_socket_handle_socket_event [C2.2:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:57.151604+0100 Sample[92026:92107483] [connection] nw_connection_get_connected_socket [C2] Client called nw_connection_get_connected_socket on unconnected nw_connection
2021-09-15 14:31:57.154312+0100 Sample[92026:92107483] TCP Conn 0x600001d7c0b0 Failed : error 0:61 [61]
2021-09-15 14:31:59.206079+0100 Sample[92026:92107483] [connection] nw_socket_handle_socket_event [C3.1:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:59.236824+0100 Sample[92026:92107483] [connection] nw_socket_handle_socket_event [C3.2:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:31:59.251927+0100 Sample[92026:92107439] [connection] nw_connection_get_connected_socket [C3] Client called nw_connection_get_connected_socket on unconnected nw_connection
2021-09-15 14:31:59.255963+0100 Sample[92026:92107439] TCP Conn 0x600001d1c210 Failed : error 0:61 [61]
2021-09-15 14:32:01.291303+0100 Sample[92026:92107439] [connection] nw_socket_handle_socket_event [C4.1:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:32:01.312406+0100 Sample[92026:92107439] [connection] nw_socket_handle_socket_event [C4.2:1] Socket SO_ERROR [61: Connection refused]
2021-09-15 14:32:01.323099+0100 Sample[92026:92107483] [connection] nw_connection_get_connected_socket [C4] Client called nw_connection_get_connected_socket on unconnected nw_connection
2021-09-15 14:32:01.326028+0100 Sample[92026:92107483] TCP Conn 0x600001d7c0b0 Failed : error 0:61 [61]
flipper: Failed to connect with the current socket provider
flipper: Use legacy socket provider
flipper: FlipperClient::onConnected
Reviewed By: passy
Differential Revision: D30900471
fbshipit-source-id: 7c242ad71306803b050d0174fc22696bb74fdba5
Summary:
This change fixes a bug with the handled flag during the certificate exchange process.
Explanation:
handled was passed by reference as &handled
Once the function goes out of scope then the reference, well, it just becomes invalid (undefined behaviour)
In some cases, it appears as 'handled' because the reference is invalid and it happens to be 'true'.
Changelog: Fixed an issue where clients would randomly not connect to Flipper. Please update FlipperKit to 0.110.0 to apply the fix: https://fbflipper.com/docs/getting-started/react-native#using-the-latest-flipper-sdk
Reviewed By: mweststrate
Differential Revision: D31017592
fbshipit-source-id: c087a769fa23de1acfd3c198b4db4d6ccdb2be90
Summary:
The changes below add the notion of alternative ports to Flipper.
These alternative ports are meant to and will be used to connect via WebSocket instead of RSocket. The name does not suggest that as to make as generic as possible so that they can be reused for different purposes in the future.
Reviewed By: passy
Differential Revision: D30898874
fbshipit-source-id: 5eed8c61b41b502c859192aaac59c284b7b36228
Summary:
I've been really sweating about this one. It looks like Google now removed NDK 21 as it's too old. However, we've been struggling with the upgrade because OpenSSL was built against an old version of the NDK/glibc/LLVM/some other stuff.
I've now managed to create an OpenSSL distribution for 1.1.1k (we had 1.1.0h before) that seems to build with this after some small modifications.
This seems to do the trick, but I wouldn't be shocked if we found some more incompatibilities further down the line.
Pull Request resolved: https://github.com/facebook/flipper/pull/2836
Test Plan:
- Locally: `./gradlew :tutorial:installDebug`. Builds, starts up. Cool.
- Public GitHub CI: Happy.
- Circle CI: Only triggers post-land. We'll see. But the setup is simple, so hopefully it should work there, too.
- Internal CI: Waiting for signal.
Reviewed By: fabiomassimo
Differential Revision: D30839209
Pulled By: passy
fbshipit-source-id: efe599f28cc0edfdf2149f905c3483555239edc0
Summary:
Abstract the socket creation from FlipperConnectionManagerImpl. Instead, use FlipperSocketProvider.
There's a default provider which will always return RSocket sockets. This provider can be changed and thus can return other implementations.
Reviewed By: fabiomassimo
Differential Revision: D30396322
fbshipit-source-id: 0583865376809260b0240e5bd653d73f2fa514b1
Summary:
It's just bad that we give a naked pointer of the connection manager to other instances. If the connection manager gets deallocated, the instances keeping a pointer to it are doomed to crash.
This change creates a wrapper on top of the pointer that can be freely shared. On deallocation, the shared wrapper gets invalidated.
Reviewed By: timur-valiev
Differential Revision: D30398466
fbshipit-source-id: 8f228e7fbaebc0ea28921409de071b58bbb69f1e
Summary:
These changes abstract RSocket from FlipperConnectionManagerImpl.
This is achieved by defining FlipperSocket.
FlipperConnectionManagerImpl uses instances of FlipperSocket and RSocket is now contained within FlipperRSocket which implements FlipperSocket.
On the changes to follow, FlipperConnectionManagerImpl will no longer reference FlipperRSocket directly thus fully abstracting the socket implementation in use.
For reviewers:
- All of the RSocket code now lives in FlipperRSocket.
- Main changes are in FlipperConnectionManagerImpl. Lambdas are used to deal with events and message handling.
- There's some very minimal serialisation additions for payloads.
Reviewed By: jknoxville
Differential Revision: D30341076
fbshipit-source-id: 54bb4878967378490710c05f729cdd7f4cf08bb8
Summary:
RSocket plays nicely with Folly and OpenSSL.
Flipper WebSocket-client uses SocketRocket which instead relies on Apple's NSInputStream and NSOutputStream types.
SSL options can be set to secure the communication in both.
Unfortunately, Apple APIs are a bit limited on the supported cryptographic formats it can accept as arguments.
SSL options require the client certificate to be set in PKCS #12 format, contrary to the existing PEM format used by RSocket.
This change adds a method to the ConnectionContext which converts and saves the client certificate in PKCS #12 format.
The method is always expected to succeed as it will only be called once a valid client certificate is available. An unlikely failure will raise an exception.
Reviewed By: fabiomassimo
Differential Revision: D30074334
fbshipit-source-id: 91a475d080569cc339b649c7302b1f28793c7de7
Summary:
It has been seen [here](https://fb.workplace.com/groups/flippersupport/permalink/1094276434386347/) that the user's app sandbox can be in a state where it might not have the device id information, but other app certificates. This causes the issue of "Timed out waiting for unknown device".
We get the deviceid from flipper into app's sandbox when cert exchange happens. So if we don't have the device id information, we can again redo the cert exchange to get the sandbox in a state where flipper connects. Thus I updated the logic of `hasRequiredFiles` which checks the required files for cert exchange.
Reviewed By: mweststrate
Differential Revision: D27265693
fbshipit-source-id: ccf311f4728837ee9385c95c38f94c9c93380feb
Summary: This gets exposed by using glog from tp2 for fbcode platform builds.
Reviewed By: aniketmathur
Differential Revision: D26515732
fbshipit-source-id: 7bb4b20a43702f9096bd6014278faffb5029712f
Summary: See the previous diffs, we pollute the global namespace here and there. Found some more missing namespace wrappers. Tried to wrap `FlipperStep` as well, which passed tests but gave weird linking errors in Wilde, so reverted that part (the name is not very ambiguous anyway)
Reviewed By: cekkaewnumchai
Differential Revision: D24193109
fbshipit-source-id: 111c479e421fdb321e898f948586229f30a7d777
Summary:
This diff adds upload and download logic for certs. It makes changes on both Flipper Client and Desktop side. With this we enable cert exchange through WWW.
Next Diffs:
1) Add Flipper state in cert provider for more debug data
2) Tests
Reviewed By: jknoxville
Differential Revision: D23092706
fbshipit-source-id: e576253606b64b62848b70203db7e09a3bd77fd9
Summary:
This diff adds a toggle setting in wilde which will enable certificate exchange through www.
Right now it just sends the information about which medium to be used for cert exchange to Flipper JS and its client side. But its implementation is not done yet.
### Flow for Wilde
Whenever user changes the setting(or when user logs out) we set the state of exchange medium and accordingly set/reset authtoken. Note at no given point we remove already existing certificates.
### Context for OSS
With this diff we introduce another way to do certificate exchange. Before this diff, we did certificate exchange by accessing the file system of app. But it turns out it's not possible to do that in applications signed by enterprise certs. Thus with this diff one can write their FlipperKitCertificateProvider and fetch the certificate from WWW.
Reviewed By: jknoxville
Differential Revision: D22896320
fbshipit-source-id: 55aef7028a62e71ba9c02f9f79acaab41d09c0c6
Summary:
Background for this diff: https://fb.quip.com/KqEfAlKYlgme
Some plugins don't respect that stuff (livefeed and graphql), but for others it seems to work fine.
This is just a PoC, there are some present bugs concerning the combination of selecting and bg plugins
Questions to investigate:
- [x] make sure that LiveFeed and GraphQL disconnect properly. There might be more plugins that need that
- [x] verifiy that we don't loose one of the original goals of background plugins, e.g. QPL collecting and sending data from device start. Does this still work as intended after this change?
- [x] how can we observe / measure improvements? Are dev builds more responsive after this? Is the layout inspector smoother for example because no QPL plugins are interweaved?
- [x] how is forward and backward compatibility?
- If Flipper is updated, but device not: No change I think, as getBackgroundPlugins() will return an empty set, and background plugins are initiated as usual, so old behavior
- If device is updated, but Flipper not, background plugins won't be started until they are selected. This is a degradation, but hopefully explainable.
- [x] Verify QPL buffer is not unbounded
- [x] Share architecutre changes with team
For Graphql updates: D20943455
Added runtime stats to monitor network traffic (sadly had to redo that since scuba couldn't handle the data format used at first, so probably will hold of landing this diff a week to make sure we can see some effects)
Follow up work:
[x] wait until we released the stat tracking before we release this, to be able to measure the effect?
[x] make sure graphql fix lands
[ ] use side effects abstraction
[ ] fix other background plugins (android only) or fix it in a generic way:
{F234394286}
Changelog: Background plugins will no longer receive a Flipper connection if they are disabled. This should significantly reduce the overall load of Flipper both on the device and desktop when unused plugins are disabled used, which could otherwise generate 10MB/s of network traffic certain scenarios. All plugins *should* be able to handle to this gracefully, but since this is quite a fundamental change, reach out to the Flipper team when in doubt!
Reviewed By: jknoxville
Differential Revision: D20942453
fbshipit-source-id: b699199cb95c1b3e4c36e026b6dfaee7d1652e1f
Summary:
Context: https://fb.workplace.com/groups/flippersupport/permalink/803808233433170/
A similar change was done earlier with the secure connection route.
This does the same for the insecure route.
Reviewed By: mweststrate
Differential Revision: D21227196
fbshipit-source-id: 844cb674b5b16033977f451bbc3d8bbc69732273
Summary:
Originally, Flipper would use exceptions for the control flow of determining if there's no desktop client available. It would catch an exception and then kick off another attempt. This is cool, but if you are debugging an application where Flipper is enabled, and you set a breakpoint to detect all thrown exceptions, then you'll see an exception thrown inside Flipper logic every couple of seconds. That makes it hard to debug what you're trying to do.
There's a workaround where you can simply open Flipper, but that's a bit annoying.
This diff changes the logic in Flipper to not use exceptions for the part of connection where it's doing the initial connect. We could apply this to `doCertificateExchange` as well, but that's actually an error there so I don't see the need to do it there as well.
Reviewed By: jknoxville
Differential Revision: D21016737
fbshipit-source-id: cbdfe2794b4d38a9e3b8304ebee845655bb26ae5
Summary:
This is in line with the most recent stable Android Studio Release.
Pull Request resolved: https://github.com/facebook/flipper/pull/958
Test Plan:
Used it myself.
Open Source CI required a higher NDK, so let's first check what CI says to that internally now.
Reviewed By: jknoxville
Differential Revision: D20794634
Pulled By: passy
fbshipit-source-id: c32f934634b036ad3c1cad9fc49541e585d64329
Summary:
The problem is that whenever an app is shutdown, and then reopened, the flipper dir gets reset when getting the CSR for connecting to flipper.
This causes the first connection attempt to fail always, and it goes through the whole cert exchange, taking longer than necessary.
Fixes it by loading the csr from disk if it's not loaded yet, without blowing away the whole certs state.
A side effect of this would be that as long as some file exists where the csr lives, flipper state would never get reset, so it wouldn't be able to fix itself automatically anymore. To keep that working, I've made `resetFlipperDir()` public and am calling it explicitly when starting certificate exchange. This should ensure that we still reset when we need to, but not unnecessarily.
The reason it went wrong is that getCSR used to be called only at cert exchange, when resetting and generating a new one was always desirable. However, when we shipped the fix for changeable android serials, it started to be used as a normal getter.
Reviewed By: timur-valiev
Differential Revision: D18834806
fbshipit-source-id: 56ca7e03e1aa9011f836bc9c021cf3048f7dc1e4
Summary:
There was an interesting problem in Flipper which I encountered. On closing our app we would deadlock. This was happening when joining the Flipper thread.
Upon investigation I found that it happened only when Flipper was not connected to the app. And digging in I found that it's because we are continually trying to connect the `FlipperClient` to the Flipper app when there is no connection. This works great, but it continues even if you have asked Flipper to terminate. So this meant that the `EventBase` never gets chance to shutdown, as it keeps getting new work to do.
The fix is to add a flag to `FlipperConnectionManagerImpl` to say if the conection is started or not. Then, if it's not started and we get a request to retry connection, then we will fail it.
Reviewed By: jknoxville
Differential Revision: D18780622
fbshipit-source-id: cce82cbb5c54e6d92ea16644c8a247bd2578ae26
Summary: in FlipperRSocketResponder::handleFireAndForget, a responder object was being conditionally (for requests with an "id" field) created, resulting in a null pointer passed into FlipperClient::onMessageReceived when no id was present. FlipperClient::onMessage received, in the meantime, unconditionally dereferences that pointer, resulting in a segmentation fault. This change creates the responder object regardless of whether or not the "id" key is present in the request object, thus avoiding passing a null pointer into FlipperClient::onMessageReceived.
Reviewed By: jknoxville
Differential Revision: D18583898
fbshipit-source-id: 2112c45bc0cd639cec908d0039d6bdaed2f61491
Summary: FlipperState may be updated from multiple threads, so it needs synchronization. Note the comments in the diff about why we drop the lock before calling out to the update listener -- this can be changed if necessary in the future.
Reviewed By: jknoxville
Differential Revision: D18095471
fbshipit-source-id: 95d558394ae1a9b7583e5a61969e1eeda6448cff
Summary:
This avoids having to perform gymnastics like in
https://github.com/facebook/react-native/pull/26697
Reviewed By: jknoxville
Differential Revision: D17735954
fbshipit-source-id: 507548aab89309beeb228b104a24af8acd10ce9a
Summary:
D17629896 was intended to fix this in ovrsource, but it turns out these changes should be made on fbsource first then get synced.
The MSVC build of OculusPCSDK has numerous warnings, including these low-hanging fruit:
```
c:\open\ovrsource\xplat\omnistore\client\common\reportsubscriptionstatetiming.cpp(28): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\databaseanalyticsmetadatatiming.cpp(23): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\sendqueuereportbacklogtiming.cpp(32): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\omnistore.cpp(192): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\omnistore.cpp(907): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\omnistore.cpp(934): warning C4101: 'e': unreferenced local variable
c:\open\ovrsource\xplat\omnistore\client\common\omnistore.cpp(946): warning C4101: 'e': unreferenced local variable
```
Clang doesn't complain, but the code is just as clear without the 'e' so best to remove.
Reviewed By: vener91
Differential Revision: D17631747
fbshipit-source-id: 0190a48e640311b40c9d1b988b0c07cfbdcfd7e5
Summary:
Background plugins are initialised when flipper connects.
But there's no isolation, so if any fail to initialize, then we don't carry on initializing the rest.
This fixes that by skipping failed ones only.
Reviewed By: passy
Differential Revision: D17600854
fbshipit-source-id: 2ef04cbcecda78ca448c2f4d56639ba63792e2f7
Summary:
- Add CSR and CSR destination to request body
- (unrelated) Rearrange the list of include files
Reviewed By: jknoxville
Differential Revision: D17346429
fbshipit-source-id: ce775998884b73e82a931f4dd8986c659a892b51
Summary:
When an operation fails, we have an error message. This was being displayed in the diagnostic screen output, but not included in the debug log.
This makes them both have same bahaviour, so they both include the error messages.
Reviewed By: passy
Differential Revision: D17181847
fbshipit-source-id: 823f73d641d2315da86a0019479716852950f9a5
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/538
Upgrades libevent to the August release 2.1.11.
Some notable things:
- The CMake file they ship with is actually broken. It contains a reference to an "uninstall.cmake" script that they don't include in the archive.
- There is some git magic in the CMake script which throws very annoying warnings if you're not in a git repository and if you are, it's still super useless because it assumes it's the libevent repo.
- I've removed the uninstall reference and replaced version detection magic with hardcoded values. The result is the "CMakeLists.txt" in the overrides folder. For future upgraders: You'll have to either remove the override or apply similar steps to the next release.
- The `event-config.h` is simply one of the outputs I found under `android/build/libevent/x86/include/event2/event-config.h`. They seem to be stable across architectures so it's easier to just copy it over than to fix the CMake logic that should actually pick it up from the Android build path.
- The cmake target names have changed and have an underscore in them, now.
- Verified with an SDK 28 x86_64 that this does fix https://github.com/facebook/flipper/issues/482.
Fixes GH482.
Reviewed By: jknoxville
Differential Revision: D17164731
fbshipit-source-id: 642744118065bea2674dbb0e1af91a11598066cc
Summary:
Don't fatal when trying to send a message to flipper that is too large.
Instead just continue to throw an exception, so the plugin will still be aware of the failure.
Reviewed By: cpojer, danielbuechele
Differential Revision: D17180334
fbshipit-source-id: 49c341a7cee579158be3878639083c6d19b3eaa3
Summary:
In tests, the instance is never initialized and it's hard to guard against null when the
instance isn't initialized to nullptr (instead being random data).
Reviewed By: ximyu
Differential Revision: D16984717
fbshipit-source-id: 414539e1117abaad16df9f9b7d3b8dbb328e38d0
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/463
Was made aware [here](https://github.com/facebook/flipper/issues/461) that
we currently don't build with NDK 20 because of Folly. The above issue exists only for x86 platform and not for other platform. I have updated the folly and RSocket. Although this diff doesn't solve the issue mentioned above for x86, but it updates the dependencies to the latest version. To mitigate temporarily, I have updated the gradle to not build for x86.
Reviewed By: passy
Differential Revision: D15713205
fbshipit-source-id: 79dd5825b0b876c87a1868fde8f3353a76012267
