-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inviting a user from a server with allow_profile_lookup_over_federation false gives a confusing error message #17269
Comments
I can repro the Error in Element nightly: Element version of the inviting user: aur/element-desktop-nightly-bin 2021051201-1 This issue promises to be very relevant with institutional servers implementing the mentioned settings for user privacy. I suggest adding info to the error message about that, and the option to invite anyway. |
I am the user who tried to reproduce the issue on element-desktop 1.7.24 (on Arch Linux) and can confirm, that there it was possible to invite users from said home server via their mxid. One just gets a warning, that the mxid might not exists, but can invite the mxid nevertheless (either via a button that ignores the warning once or for the future as well). This was even the case if one already had a direct chat with the user open. Once this regression is fixed, maybe a note, that this could be due to privacy settings on the remote server, could be added. |
This still seems to be a problem with Element Desktop version 1.9.3. |
Inviting someone using the "Invite to this room" button yields:
I only have the option to press OK. My client made a request to In fairness to Element-Web, the spec says the only response codes are 200 and 404. Spec deficiency? https://spec.matrix.org/v1.1/client-server-api/#get_matrixclientv3profileuserid |
Some servers may not allow profile lookup over federation, and thus respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403. For example, Synapse can be configured to behave in this way by setting: allow_profile_lookup_over_federation=false Thus, this behavior already exists in the wild, and may cause issues for clients such as element-hq/element-web#17269. Synapse could alter its behavior and return an HTTP 404 in these cases, but amending the Spec seems preferable to align with extand behavior. Further, allowing HTTP 403 gives clients more specific information as to why a request has failed, enabling more precise error handling. Signed-off-by: Dan Callahan <[email protected]>
Some servers may not allow profile lookup over federation, and thus respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403. For example, Synapse can be configured to behave in this way by setting: allow_profile_lookup_over_federation=false Thus, this behavior already exists in the wild, and may cause issues for clients such as element-hq/element-web#17269. Synapse could alter its behavior and return an HTTP 404 in these cases, but amending the Spec seems preferable to align with extand behavior. Further, allowing HTTP 403 gives clients more specific information as to why a request has failed, enabling more precise error handling. Signed-off-by: Dan Callahan <[email protected]>
Some servers may not allow profile lookup over federation, and thus respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403. For example, Synapse can be configured to behave in this way by setting: allow_profile_lookup_over_federation=false Thus, this behavior already exists in the wild, and may cause issues for clients such as element-hq/element-web#17269. Synapse could alter its behavior and return an HTTP 404 in these cases, but amending the Spec seems preferable to align with extant behavior. Further, allowing HTTP 403 gives clients more specific information as to why a request has failed, enabling more precise error handling. Signed-off-by: Dan Callahan <[email protected]>
The Synapse team would like to expand the Matrix spec to codify HTTP 403 in this instance. That proposal is at matrix-org/matrix-spec-proposals#3530. |
* Add HTTP 403 to possible profile responses Some servers may not allow profile lookup over federation, and thus respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403. For example, Synapse can be configured to behave in this way by setting: allow_profile_lookup_over_federation=false Thus, this behavior already exists in the wild, and may cause issues for clients such as element-hq/element-web#17269. Synapse could alter its behavior and return an HTTP 404 in these cases, but amending the Spec seems preferable to align with extant behavior. Further, allowing HTTP 403 gives clients more specific information as to why a request has failed, enabling more precise error handling. Signed-off-by: Dan Callahan <[email protected]> * Update changelogs/client_server/newsfragments/3530.clarification Co-authored-by: Travis Ralston <[email protected]> * Annotate misc data about error Co-authored-by: Travis Ralston <[email protected]> Co-authored-by: Travis Ralston <[email protected]>
The message displayed by element-web when inviting over the GUI seems to have changed, but the result is still the same. In the Preferences there is the option |
I took a closer look at this one. If setting
Then this dialogue appears: If I uncheck With After looking around in the code it looks like a bug that the „may not exist“ dialogue doesn't show up. |
We tried inviting a user from a server with
allow_profile_lookup_over_federation: false
andinclude_profile_data_on_invite: false
(not sure which of those settings is actually relevant here) to an invite-only room. This causes Element to say (I can't remember the exact error message, sorry) that the profile might be invalid and won't let us inviting that user. The error on the inviting user's home server is:Disabling the "warn before sending invites to invalid Matrix IDs" setting in the Element settings allows inviting the user and the invited user can join the room.
This is a least somewhat inconsistent in the wording as the Matrix ID is not invalid and it is not clear that it is possible to switch off that setting.
It also seems prior Element versions did not hinder inviting users from home servers with the above settings, some other user tried to reproduce this issue on Element 1.7.24 and did not see the above error message.
Element version of the inviting user: 1.7.27 macOS Desktop client
Synapse version of the inviting user: 1.33.2
Synapse version of the invited user: 1.31.0
The text was updated successfully, but these errors were encountered: