Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Deactivating an account as an application service using user_id yields a response not containing id_server_unbind_result #16608

Closed
ew-at-vier opened this issue Nov 7, 2023 · 1 comment · Fixed by #16617
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@ew-at-vier
Copy link
Contributor

Description

The scenario is as follows:

  • No 3PIDs or third party identity servers have been used on the synapse server involved.
  • There is a configured application service.

The application service wants to deactive an account in its namespace and issues a post
request to

/_matrix/client/v3/account/deactivate?user_id=<some user id from application service user namespace>

with request body of

{}

Synapse answers with http status code 200 and a response body of

{}

not containing id_server_unbind_result in violation of Client Server API Spec accountdeactivate which states as description of the response field id_server_unbind_result:

Required: An indicator as to whether or not the homeserver was able to unbind the user’s 3PIDs from the identity server(s). success indicates that all identifiers have been unbound from the identity server while no-support indicates that one or more identifiers failed to unbind due to the identity server refusing the request or the homeserver being unable to determine an identity server to unbind from. This must be success if the homeserver has no identifiers to unbind for the user.
One of: [success, no-support].

So in this case, it should have answered with a response body of { "id_server_unbind_result": "success" }.

Steps to reproduce

  • use clean synapse instance
  • configure an application service
  • create a user as an application service
  • deactivate the user as an application service using the user_id feature explained in Application Service API Spec 1.3.1. Identity assertion
  • observe a response not containing id_server_unbind_result.

Homeserver

From hub.docker.com matrixdotorg/synapse:v1.92.3

Synapse Version

{"server_version":"1.92.3","python_version":"3.11.5"}

Installation Method

Docker (matrixdotorg/synapse)

Database

sqlite

Workers

I don't know

Platform

Observed on my developer machine

NixOS 23.05 / amd64

Also observed in an deployment in nomad, I think the nodes are either rocky linux or centos 7.

Configuration

Just an application service with a user namespace and room alias namespace.

Relevant log output

Sorry not observed.

Anything else that would be useful to know?

I assume synapse/rest/client/account.py:307 is the culprit.

Maybe just put return 200, {"id_server_unbind_result": "success"} there to satisfy the spec?

@reivilibre
Copy link
Contributor

Thanks for your report! Looks like it should just process the deactivation in the same way, except for skipping the user-interactive authentication. I've put up #16617 to fix this.

@reivilibre reivilibre added A-Spec-Compliance places where synapse does not conform to the spec S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. O-Uncommon Most users are unlikely to come across this or unexpected workflow labels Nov 9, 2023
reivilibre added a commit that referenced this issue Nov 9, 2023
…entifiers for Application Service users when deactivated and would not emit a compliant response. (#16617)

* Don't skip unbinding 3PIDs and returning success status when deactivating AS user

Fixes #16608

* Newsfile

Signed-off-by: Olivier Wilkinson (reivilibre) <[email protected]>

---------

Signed-off-by: Olivier Wilkinson (reivilibre) <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
2 participants