Add support for checking the ESS config in Element Pro - #7302
Conversation
|
📱 Scan the QR code below to install the build (arm64 only) for this PR. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #7302 +/- ##
===========================================
- Coverage 80.55% 80.51% -0.04%
===========================================
Files 2772 2780 +8
Lines 80738 80788 +50
Branches 11011 11017 +6
===========================================
+ Hits 65040 65049 +9
- Misses 11447 11484 +37
- Partials 4251 4255 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
There is an implementation without OkHttp (creating temporary Rust clients like iOS does) in https://github.com/element-hq/element-x-android/tree/feat/add-ess-config-endpoint-support-with-assistedinject. |
0cbd738 to
fcad692
Compare
|
I've merge the branch mentioned above, rebased the code and split it into new commits so it's hopefully easier to understand. I think you can review it now @ganfra . FWIW the temporary client approach is what iOS does and should help keep the network stack consistent in the authenticating and already authenticated scopes. |
ganfra
left a comment
There was a problem hiding this comment.
Thanks, looking solid. Just small remarks!
| return when (val cacheData = store.get(checkedHost)) { | ||
| is WellknownRetrieverResult.Success -> { | ||
| Timber.d("Using cached well-known for domain $checkedHost") | ||
| fetchElementWellKnown(checkedHost, source, store) |
There was a problem hiding this comment.
Is the fetch here necessary? And if yes, should we launch the fetch on a separate coroutine?
There was a problem hiding this comment.
Oops, you found some test code I forgot to remove. Thanks!
|
|
||
| @BindingContainer | ||
| @ContributesTo(SessionScope::class) | ||
| @ContributesTo(SessionScope::class, replaces = [GetUrlResolver::class]) |
There was a problem hiding this comment.
Do we need this replaces? This sounds a bit weird
|
|
||
| package io.element.android.libraries.matrix.api | ||
|
|
||
| fun interface GetUrlResolver { |
There was a problem hiding this comment.
GetUrl is a bit misleading? On first hand I though it was just returning an url I know it comes from the rust sdk name, but could be something like UrlContentFetcher or HttpGetExecutor?
| * Note: this client implements an [AutoCloseable] interface, so using [AutoCloseable.close] or [AutoCloseable.use] will clean up any resources associated | ||
| * with it, such as temporary files. | ||
| */ | ||
| interface TemporaryMatrixClient : GetUrlResolver, AutoCloseable |
There was a problem hiding this comment.
Maybe it should be called UnauthenticatedMatrixClient? not sure...
Also, does it need to be part of the api module?
There was a problem hiding this comment.
Maybe it should be called UnauthenticatedMatrixClient? not sure...
That's what I had at first, but I thought the temporary part was more important... now I'm not so sure.
Also, does it need to be part of the api module?
I think so, otherwise how would you use the TemporaryMatrixClientFactory to return one of these?
| WellknownRetrieverResult.NotFound | ||
| } else { | ||
| WellknownRetrieverResult.Error(e) | ||
| val checkedHost = URL(host.ensureProtocol()).host ?: host |
There was a problem hiding this comment.
I think host never returns null, so the fallback doesn't work
|
@ganfra I uploaded some changes to fix the issues you mentioned, in case you want to double check. Also, remember the enterprise PR should be reviewed too before this one can be merged. |
In the future, we want to move the enterprise config to the private Element Pro repo, this is a first step
This allows us to decide where to get the remote enterprise config from.
Implementations should just perform a GET request and return the raw body as bytes
For Pro, this will check different remote config sources and return the result. For FOSS, this will always return a `NotFound` result
This is an abstraction over an actual unauthenticated `Client` from the SDK that implements `GetUrlResolver`, and is supposed to be short-lived. With this, we can use the SDK network stack to perform arbitrary GET url operations. The `AutoCloseable` implementation makes it easier to clean up any leftover local config after using this temporary client.
Also, allow instantiating it using a factory: with this we can always decide where to take the config from and how to do it Do the same for `ElementWellknownStore` so we can store and restore the values for different sources (endpoints) independently
…ts where possible
…o build it every time there
…the enterprise module
… up to date in the store in `DefaultWellknownRetriever`
…ientFactory.createTemporaryMatrixClient` to just `create`
6822a1b to
4bfa9e6
Compare
|



Content
ElementWellKnownSourceenum to allow deciding where to get the remote enterprise config from.RemoteEnterpriseConfigServiceto make this decision (this is implemented mostly in the enterprise code).UrlContentFetcherwhich is a component to fetch data from any URL using a GET request and implement 2 versions: one with a temporary and unauthenticated SDK client for unauthenticated requests and another one withRustMatrixClientso we perform the request using the authenticated client in the SDK.SessionElementWelknownRetrieverand move the logic toWellknownRetriever, allowing us to use any of the 2UrlContentFetcherinstances to actually fetch the data without having to create 2 variations of this class for the 2 DI scopes.RemoteEnterpriseConfigServiceas much as possible. The only exception is inDefaultAccountProviderAccessControlbecause we want to always check the legacy element well known URL there to check for therequires_element_proconfig there.The PR in enterprise repo is https://github.com/element-hq/element-android-enterprise/pull/38.
Motivation and context
https://github.com/element-hq/element-enterprise/issues/297
Tests
With an Element Pro version, check the new endpoint is checked, then the existing well known one is.
You can also check unauthenticated ones go through OkHttp and authenticated ones from the SDK, based on the logs.
Tested devices
Checklist