Open tgurr opened 4 years ago
and also in config.json of riot
It is not a config.json option.
What do your user names look like, @bob:matrix.corporate.local
? or is it just :corporate.local
?
and also in config.json of riot
It is not a config.json option.
Hence my request to please add such an option.
What do your user names look like,
@bob:matrix.corporate.local
? or is it just:corporate.local
?
They're just :corporate.local
.
Hence my request to please add such an option.
Product team specifically said well-known only
They're just :corporate.local.
Then your well-known URL is wrong;
I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:
It should be
It should be
As I explained corporate.local points to the active directory domain controllers on which I don't want and won't install an additional web server in any form. I'm pretty sure I'm not the only one with that problem.
Sorry, missed that.
Well as per the Matrix spec, that is the only place the well-known is looked up. https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri
Hence my request to please add such an option.
Product team specifically said well-known only
Well as per the Matrix spec, that is the only place the well-known is looked up. https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri
Maybe the product team could reconsider it's decision as there obviously seem to exist use cases for that. I fail to see where having an additional configure option would hurt.
It wouldn't apply to riot-android, riotX-android, riot-ios the well-known route was chosen for consistency between clients (not that they support it yet but still)
the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product
It wouldn't apply to riot-android, riotX-android, riot-ios the well-known route was chosen for consistency between clients (not that they support it yet but still)
the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product
Which wouldn't be a problem (in our case) as I can and have configured a proper https://corporate.local/.well-known/matrix/client reachable from the outside/internet perfectly well. We could argue how stupid it is to have the same domain internally and externally but it's how it was done and out of my control.
We'll track this as a suggestion for now. I would helpful to hear from other deployments that might also be in this situation of being unable to deploy .well-known so we can consider alternative options.
oops, didn't realise you already changed
I would helpful to hear from other deployments that might also be in this situation of being unable to deploy .well-known so we can consider alternative options.
+1 for us. Please understand that not all sysadmins out there can easily accomplish such a requirement. Since we are discussing about element-web here, it would be so far more simple to make this setting available in the config.json
file.
Does the io.element.e2ee setting do anything in the client these days?
I've been trying to get this to work, but have had no luck, client doesn't seem to retrieve .well-known file at all, and if I grep through the element-web codebase for e2ee, the only hits I get are in the docs MD files and changelog. (This may be me not understanding to source structure, but I do find it quite odd)
Thanks for the super-speedy reply :) I do have a small followup question.
When does Element-web query those? Is it only done on login, or should it be every time I open the client after having closed the tab/browser?
Having my apache logs open, I get no hits on the well-known file, not even 404s
It does it at app launch and every 2h whilst running.
Are you definitely looking at the right logs?
If your Synapse is running at synapse.domain.org
but your usernames are @something:domain.org
then the well-known is at https://domain.org/.well-known/matrix/client
Yes, I found that info in some other threads, users are @user:sub.domain.tld and server is running at sub.domain.tld
I'm looking at a combined log for both sub.domain.tld and domain.tld, just in case.
I suggest looking at the client's/browser's Network log instead, as that's the only one that is guaranteed, there's many things in the path of the network which could go awry.
I can see it does find the .well-known file in the network log, and it is io.element.e2ee that is the correct key, as per https://github.com/vector-im/element-web/blob/develop/docs/e2ee.md?
Am I on the other hand wrong in understanding that it should have a visual impact in the client? Can I check somewhere that the client has gotten the key?
In the Create a private room
dialog it defines the default state of the Enable end-to-end encryption
checkbox
It also is used to decide whether DMs should be e2ee by default, try create a DM and see if it is automatically E2EE or not
I can see the toggle in the Create Room (I think this was always the case, though), but direct conversations are still encrypted upon creation.
EDIT: Removed link
I can see the toggle in the Create Room
Is that toggle (e2ee) on or off by default though?
In my case (default) it is on-by-default when I switch Make this room public
OFF
On by default here as well, when I open create room.
And, there are no toggles when connecting to "People", I just get a conversation looking like this
What do you get when you run mxMatrixClientPeg.matrixClient.getClientWellKnown()
in the Browser Console of a running Element?
I get an empty object, {}
Can this be CORS related, the client is running on (EDIT: Removed link), but I can see the request for the well-known file in the network tab, and there is the expected data in the response.
Yeah if the request in the network tab is successful then I'd expect it to be in getClientWellKnown
- you have stumbled upon a bug for which I have no explanation
I think maybe my browser have this cached, if I try in another browser, I actually do get a CORS error.
Man, this one is all on me, thank you so much for your help, and sorry to have wasted your time.
Maybe I should write a bridge to chat via GitHub issue comments ;)
I am running into this. I can't use .well-known
at the server_name, I am using SRV records and Element's config.json
>default_server_config
for server discovery. The spec made it seem like this was fully supported, but now I cannot set important client settings.
I have tried putting the io.element.e2ee
in the default_server_config
of Element, but that doesn't appear to be read.
Please move configuration options somewhere where every spec-following deployment can set them.
Please move configuration options somewhere where every spec-following deployment can set them.
What makes you spec-following distinctly vs someone who hosts a .well-known/matrix/client
file? Your SRV record is entirely unrelated to this file, SRV is for server-server API discovery only, not intended for clients.
I did say every spec-following deployments... I am not asking you to choose...
I am not asking you to stick with using the server-discovery mechanism to publish those settings either. If it can't be done that way, maybe do it a different way, such as config.json
.
I have made a small attempt to update the synapse documentation to be more explicit about this particular topic, would love to get this audience's eyes on it to make sure this might help eliminate confusion in the future: https://github.com/matrix-org/synapse/pull/14959
Description
Trying to implement https://github.com/vector-im/riot-web/pull/13914 I run into an issue.
I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:
{"m.homeserver": {"base_url": "https://matrix.corporate.local/"}, "m.identity_server": {"base_url": "https://matrix.corporate.local"}, "im.vector.riot.e2ee": {"default": false}}
and also in config.json of riot
Now my question is if that isn't enough and if not if we could please have the option to specify this via config.json of riot as well since that doesn't seem to work right now(?).
Because our synapse is running on matrix.corporate.local in a corporate environment where corporate.local points to the active directory servers on which I can't and also don't want to run a webserver to just serve a .well-known for the domain.
Steps to reproduce
Version information
For the web app: