MSC4250: Authenticated media v2 (Cookie authentication for Client-Server API) #4250
Conversation
turt2live
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
- Evidence that this actually works in Firefox private browsing mode and other similar environments
| [Service Workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) are unavailable, | ||
| leaving the client two options: | ||
|
|
||
| 1. Buffer *all* media into a [Blob](https://developer.mozilla.org/en-US/docs/Web/API/Blob), like they |
There was a problem hiding this comment.
Another alternative: Stream the image via plain old fetch into OPFS and then load it from there. OPFS is not always available in private tabs. In that case the media can be streamed into IndexedDb too. That's what Trixnity does.
| -> 401 M_MISSING_TOKEN | ||
| ``` | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
How well does this with with CDNs? (especially in comparison with the Auth header approach). As I assume this is the main reason that S3 & Discord etc use timed/hashed query params...
There was a problem hiding this comment.
It should have zero impact because we still hit the homeserver before redirection.
| affected users a chance at seeing media again. This proposal is heavily inspired by | ||
| [issue #1949](https://github.com/matrix-org/matrix-spec/issues/1949) which explores some potential | ||
| options in this area, and puts forward [Cookies](https://en.wikipedia.org/wiki/HTTP_cookie) as the | ||
| best way to solve the issue. This is an opt-in authentication mechanism for specific Client-Server API |
There was a problem hiding this comment.
I think it was more siding with timed URLs, at least as far as my reasoning went (although this is great as an MSC for the cookie auth option regardless: I probably ought to write up an MSC for the timed auth option).
There was a problem hiding this comment.
"this" is meant to be the MSC rather than issue - will clarify
| Servers SHOULD note that some browsers and cookie jar implementations may restore expired cookies, and | ||
| SHOULD therefore check expiration against an internal database rather than rely on the client-supplied | ||
| value. |
There was a problem hiding this comment.
Not quite sure how questionable cookie jar impls are relevant here: isn't rejecting expired cookies a fundamental security requirement for the server? Or maybe I've misunderstood what this is trying to say.
There was a problem hiding this comment.
It was a weird thing for the MDN page to say in a brief scroll, so carried here as a recommendation.
| calling [`/sync`](https://spec.matrix.org/v1.13/client-server-api/#get_matrixclientv3sync) or | ||
| [`/whoami`](https://spec.matrix.org/v1.13/client-server-api/#get_matrixclientv3accountwhoami) (for |
There was a problem hiding this comment.
I think I was coming down on the side of a dedicated 'cookie pls' endpoint rather than dual-purposing sync or whoami, since the only benefit would be to save a few requests by tacking it onto sync requests, whereas you would lose precise control on when the cookie got refreshed and add interactions between media and sync that aren't really necessary. For whoami I really don't see any benefit to dual-purposing.
There was a problem hiding this comment.
A benefit of dual purpose is the client doesn't have to care about the cookie at all: it'll get appended by their http client automatically, and the server can decide when to override it. This also allows a server to set HttpOnly if it wants.
Rendered
Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published as a Trust & Safety team member allocated in full to the Foundation.
Fixes matrix-org/matrix-spec#1949