| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
matrix-org/markjh/history_for_rooms_that_have_been_left
SPEC-216: Allow users to view the history of rooms that they have left.
|
| | |
|
| |
| |
| |
| | |
they left
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of weird caveats:
* If we can't validate your macaroon, we fall back to checking that
your access token is in the DB, and ignoring the failure
* Even if we can validate your macaroon, we still have to hit the DB to
get the access token ID, which we pretend is a device ID all over the
codebase.
This mostly adds the interesting code, and points out the two pieces we
need to delete (and necessary conditions) in order to fix the above
caveats.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Removes device_id and ClientInfo
device_id is never actually written, and the matrix.org DB has no
non-null entries for it. Right now, it's just cluttering up code.
This doesn't remove the columns from the database, because that's
fiddly.
|
|
|
|
| |
We're about to have two kinds of token, access and refresh
|
| |
|
|
|
|
| |
setup_test_homeserver function in utils.
|
|
|
|
| |
device_id in the internal meta data for the event along with the transaction id when sending events
|
| |
|
|
|