MSC2949: Proposal to clarify "Requires auth" and "Rate-limited" in the spec #2949
Conversation
Signed-off-by: Tulir Asokan <[email protected]>
| None that I can think of. | ||
|
|
||
| ## Security considerations | ||
| None that I can think of. |
There was a problem hiding this comment.
There are some endpoints that redirect, possibly to external sites. Adding an Authentication header to those in a browser environment will result in the browser sending the same Authentication header in the new request. There is not even a way to prevent this (I spent a long time researching this recently).
There was a problem hiding this comment.
Huh, interesting. I guess in those cases the spec should explicitly forbid adding the auth headers. Are there any current endpoints that will redirect to an external site and are used after logging in, or should it just be added as a note for potential future endpoints?
There was a problem hiding this comment.
The only one in the client-server spec that explicitly mentions redirects is the one for SSO. Not sure about GET /_matrix/media/r0/download/{serverName}/{mediaId}, it seems realistic one would implement that via redirects, but the spec doesn't mention that possibility.
| Inconsistencies in the "Rate-limited" value doesn't have consequences that are | ||
| as obvious, but it is a similar problem nevertheless: Synapse has rate limits | ||
| on multiple endpoints that are marked as not rate limited in the spec. |
There was a problem hiding this comment.
this is a documentation bug, not something that needs an MSC
| interpreted. There are already multiple endpoints, such as [GET /publicRooms], | ||
| which don't require auth in the spec, but may require auth in [some server | ||
| implementations]. |
There was a problem hiding this comment.
these sorts of auth differences should be their own MSCs, or point 2 of the proposal below should be expanded upon to clarify the benefits.
turt2live
added
kind:maintenance
| 2. Recommend that clients always include authorization in requests to the | ||
| homeserver if they have an access token. |
There was a problem hiding this comment.
What is the benefit of having a “maybe” if clients are supposed to send the token anyway? The “Change all the potentially-requires-auth endpoints to always require auth.” makes more sense to me.
There was a problem hiding this comment.
The idea is that a client library could refuse to send a request without an access token to an endpoint that definitely requires auth. For 'maybe', you would disable that check and send the auth token if you have one, but still attempt the request if you don't.
| ## Security considerations | ||
| None that I can think of. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
For rate limiting, we can instead recommend how much endpoints should be rate limited.
Rendered