Skip to content
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

Closed
thegcat opened this issue May 12, 2021 · 7 comments · Fixed by matrix-org/matrix-react-sdk#8504
Assignees
Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@thegcat
Copy link

thegcat commented May 12, 2021

We tried inviting a user from a server with allow_profile_lookup_over_federation: false and include_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:

May 11 22:00:12 matrix matrix-synapse-synchrotron9100[3783]: synapse.http.matrixfederationclient - 612 - WARNING - GET-67720 - {GET-O-51} [other.home.server] Request failed: GET matrix://other.home.server/_matrix/federation/v1/query/profile?user_id=%40some.user%3Aother.home.server&field=displayname: HttpResponseException('403: Forbidden‘)

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

@HarHarLinks
Copy link
Contributor

HarHarLinks commented May 12, 2021

I can repro the Error in Element nightly: Failed to invite the following users to chat: @mxid:server.tld

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.

@behrmann
Copy link

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.

@lxp
Copy link

lxp commented Oct 29, 2021

This still seems to be a problem with Element Desktop version 1.9.3.

@DMRobertson
Copy link

Inviting someone using the "Invite to this room" button yields:

Failed to invite users to the room:

You do not have permission to invite people to this room.

Screenshot from 2021-11-19 12-26-20

I only have the option to press OK.

My client made a request to https://matrix-client.matrix.org/_matrix/client/r0/profile/<MXID> which returned 403. I'm guessing that Element Web doesn't have logic to handle a 403 or otherwise doesn't expect it? The surprising thing is that we don't seem to have tried to make an /invite/ request at all.

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

callahad added a commit to callahad/matrix-doc that referenced this issue Nov 25, 2021
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]>
callahad added a commit to callahad/matrix-doc that referenced this issue Nov 25, 2021
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]>
callahad added a commit to callahad/matrix-doc that referenced this issue Nov 25, 2021
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]>
@callahad
Copy link

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.

turt2live added a commit to matrix-org/matrix-spec-proposals that referenced this issue Dec 29, 2021
* 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]>
@johannes-krude
Copy link
Contributor

johannes-krude commented Apr 1, 2022

The message displayed by element-web when inviting over the GUI seems to have changed, but the result is still the same.

screenshot_2022-04-01_17:04:51

In the Preferences there is the option Prompt before sending invites to potentially invalid matrix IDs. Disabling this option only changes the behavior of \invite, but not when inviting through the GUI. This option also does not really solve the problem, since I can not control this option for the element-web of the user who wants to invite me over federation.

@novocaine novocaine added T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Occasional Affects or can be seen by some users regularly or most users rarely and removed T-Enhancement labels Apr 19, 2022
@weeman1337
Copy link
Contributor

weeman1337 commented May 3, 2022

I took a closer look at this one.

If setting allow_profile_lookup_over_federation: false the response is now

403:
{
  "errcode":"M_FORBIDDEN",
  "error":"Profile lookup over federation is disabled on this homeserver"
}

Then this dialogue appears:

grafik

If I uncheck Prompt before sending invites to potentially invalid matrix IDs in the preferences it is working.


With allow_profile_lookup_over_federation: true and a non-existing user leads to

grafik


After looking around in the code it looks like a bug that the „may not exist“ dialogue doesn't show up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants