MSC2499: Fixes for Well-known URIs #2499
Conversation
aaronraimist
changed the title
aaronraimist
force-pushed
the
fix-client-well-known
branch
from
78d3a47 to
9270c4c
Compare
Signed-off-by: Aaron Raimist <[email protected]>
aaronraimist
force-pushed
the
fix-client-well-known
branch
from
9270c4c to
2f19796
Compare
turt2live
added
proposal-in-review
kind:maintenance
| changed from `FAIL_PROMPT` to `IGNORE` so that a non 200 response is treated in the same | ||
| way as 404. This change is intended to fix issues like https://github.com/vector-im/riot-web/issues/7875. | ||
|
|
||
| This change does have potential security concerns, see https://github.com/vector-im/riot-web/issues/11136. |
There was a problem hiding this comment.
In relation to this issue, I think it's worth clarifying in the spec that as long as a fully qualified MXID is supplied and the .well-known lookup fails for whatever reason, the client MUST NOT use whichever default server it might have. IGNORE description in the spec isn't quite clear on that; actually, it almost encourages the behaviour described in the issue by saying that the client can use "default values" to fill in required parameters.
There was a problem hiding this comment.
You know what, actually reading the spec again maybe FAIL_PROMPT is the correct thing to do but Riot just isn't doing that. Riot is doing something closer to a FAIL_ERROR, rather than a FAIL_PROMPT. I'm thinking IGNORE should just be removed from the spec completely and 3a and 3b should be a FAIL_PROMPT.
There was a problem hiding this comment.
I wouldn't be so harsh on IGNORE - it allows the user to go without an unneeded roadbump in 3a in case the client managed to get the clear message from the server that there's no .well-known support here. The IGNORE description is too affording though.
There was a problem hiding this comment.
Yeah it would be nice if there was no extra step but if using defaults values is removed from IGNORE then how will the client find out the server URL? The only way is to prompt the user unless I am missing something. So it would be the same as FAIL_PROMPT.
There was a problem hiding this comment.
Probably the spec should be clear about the scope of cases for auto-discovery. Specifically, if the user entered a fully qualified MXID, only then auto-discovery kicks in. Using the default value in a situation when the serverpart is already provided but the server happens to have .well-known not quite ideally configured (i.e. step 3b) is definitely the wrong way out. Asking the user to confirm that the server is correct because auto-discovery fell short is the right way but both IGNORE and FAIL_PROMPT speak about that anyway.
There was a problem hiding this comment.
FAIL_PROMPT is probably still correct, I think. Element (then Riot) likely has a bug in this area, though its UX doesn't really lend itself to "prompting" the user. It should probably offer the ability to continue anyways, though.
There was a problem hiding this comment.
Yeah I'll take this out.
aaronraimist
changed the title
Signed-off-by: Aaron Raimist <[email protected]>
| changed from `FAIL_PROMPT` to `IGNORE` so that a non 200 response is treated in the same | ||
| way as 404. This change is intended to fix issues like https://github.com/vector-im/riot-web/issues/7875. | ||
|
|
||
| This change does have potential security concerns, see https://github.com/vector-im/riot-web/issues/11136. |
There was a problem hiding this comment.
FAIL_PROMPT is probably still correct, I think. Element (then Riot) likely has a bug in this area, though its UX doesn't really lend itself to "prompting" the user. It should probably offer the ability to continue anyways, though.
| 1. The maximum size of size of the well-known file is 51200 bytes. A client or server | ||
| requesting a well-known file MUST abort and FAIL_PROMPT if the response exceeds 51200 bytes. |
There was a problem hiding this comment.
This isn't a super realistic thing that can be applied by clients: if the server admin has configured the server so badly that a 10gb JSON file is being served then so be it. It's just not in the server admin's interest to attack bandwidth in this way given the costs they would be incurring from their ISP/service provider.
There was a problem hiding this comment.
At least for native clients (and servers) it's fairly easy to abort on 51201st byte but FAIL_PROMPT looks a bit dubious here: should the client re-request .well-known or rather just continue (rather than abort) receiving the payload after confirming with the user? And yes, generally there's no incentive to attack in that way of course; but a recommendation to protect receiving sides from such misconfigurations wouldn't hurt, would it? Maybe not as MUST but as SHOULD.
There was a problem hiding this comment.
I'm not convinced that this endpoint specifically needs this recommendation though: surely we should be applying this to all endpoints like profiles, sync, etc...
It feels like another MSC's problem.
There was a problem hiding this comment.
That's fine, I can leave it to another MSC. The main reason for including it here is because Synapse has already implemented this limit for the server well-known so a well-known bigger than that already isn't going to work with most servers. If it was specced then at least people could expect there is some reasonable limit on the size.
There was a problem hiding this comment.
I would be a bit surprised if people expected 1mb json files to work for this use case, honestly. I think it's reasonable for clients/servers to impose their own limits, and iirc Synapse only really limited the JSON file size on server-server because federation has tiny timeouts (typically), so read delays are not ideal.
Signed-off-by: Aaron Raimist <[email protected]>
Co-authored-by: Travis Ralston <[email protected]>
Signed-off-by: Aaron Raimist <[email protected]>
turt2live
added
the
needs-implementation
Signed-off-by: Aaron Raimist <[email protected]>
Co-authored-by: Vladimir Panteleev <[email protected]>
Rendered
Intended to address:
https://github.com/matrix-org/matrix-doc/issues/1919
https://github.com/matrix-org/matrix-doc/issues/1896
https://github.com/matrix-org/matrix-doc/issues/2335
If there are any other issues with the client well-known that I've missed let me know so there doesn't need to be a followup MSC.