| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This closes #2602
v1auth was created to account for the differences in status code between
the v1 and v2_alpha revisions of the protocol (401 vs 403 for invalid
tokens). However since those protocols were merged, this makes the r0
version/endpoint internally inconsistent, and violates the
specification for the r0 endpoint.
This might break clients that rely on this inconsistency with the
specification. This is said to affect the legacy angular reference
client. However, I feel that restoring parity with the spec is more
important. Either way, it is critical to inform developers about this
change, in case they rely on the illegal behaviour.
Signed-off-by: Adrian Tschira <nota@notafile.com>
|
|
|
|
|
|
| |
The imports were shuffled around a bunch in py3
Signed-off-by: Adrian Tschira <nota@notafile.com>
|
| |
|
| |
|
|
|
|
| |
pointless function is pointless
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In order that we can fill the gap after a /sync, make it possible to paginate
forwards from a stream token.
|
| |
|
|
|
|
| |
... merely because I was trying to figure out how it worked, and couldn't.
|
|
|
|
|
|
|
| |
This follows the same flows-based flow as regular registration, but as
the only implemented flow has no requirements, it auto-succeeds. In the
future, other flows (e.g. captcha) may be required, so clients should
treat this like the regular registration flow choices.
|
|
|
|
|
| |
This is done by using the same /leave flow as you would use if you had
already accepted the invite and wanted to leave.
|
|\
| |
| |
| |
| | |
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
|
| |
|
|
|