matrix-org / matrix-org/matrix-spec
support POST requests to `preview_url`
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 330
- Forks
- 150
- Avg merge
- 2h 21m
- Merged PRs (30d)
- 3
Description
Hello,
we reviewed our homeserver and reverse proxy logs and discovered the following issues that may effect integrity of matrix.
At first we figured out that the element client calls the endpoint `preview_url` with GET method for encrypted rooms even if the endpoint was disabled on synapse server. This happens every time a user sends a message that only contains a url.
We reported that behavior as an issue under https://github.com/matrix-org/synapse/issues/11591.
While discussing this @squahtx told that the the synapse homeserver replaces (redact) sensitive data like `access_token` and `clients_access` within the logging string.
In our opinion, redacting these events in homeserver isn't the solution. Sensitive data like access_token, client_access or urls shouldn't have to send with GET, because this will expose potential sensible data to the synapse server, the reverse proxy and every services that parse these logs.
First thoughts:
- change [GET /_matrix/media/v3/preview_url](https://spec.matrix.org/v1.1/client-server-api/#get_matrixmediav3preview_url) to POST
- promote activated features to clients (aka smtp ehlo)
- remove endpoint preview_url endpoint
- disable support of sending access_token via get
best regards
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the GET /_matrix/media/v3/preview_url entry in the linked Matrix Client-Server API specification and review the related Synapse issue 11591. The requested outcome is not settled: decide between POST support, removing the endpoint, or disabling access_token in GET requests, then update the specification to reflect the chosen design.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100