[WIP] device dehydration #7955
[WIP] device dehydration #7955
Conversation
synapse/rest/client/v1/login.py
Outdated
| return ( | ||
| 200, | ||
| await self.device_handler.rehydrate_device( | ||
| submission.get("dehydration_token") |
There was a problem hiding this comment.
We probably want to use assert_params_in_dict for dehydration_token since it is required -- this will raise a sane error message. (This is true for any parameters that are required in the added endpoints.)
| @@ -401,6 +423,52 @@ async def _do_jwt_login(self, login_submission: JsonDict) -> Dict[str, str]: | |||
| return result | |||
|
|
|||
|
|
|||
| class RestoreDeviceServlet(RestServlet): | |||
| PATTERNS = client_patterns("/org.matrix.msc2697/restore_device") | |||
There was a problem hiding this comment.
Not sure if this is supposed to show up only in unstable or also r0 (the current code would do both).
| "dehydration_token": token, | ||
| } | ||
|
|
||
| # FIXME: call callback? |
There was a problem hiding this comment.
The documentation about what this callback might be (see the check_auth info in there) is less than ideal. It comes from password auth modules and might be None or a Callable that is "called with the result from the /login call (including access_token, device_id, etc.)"
I do not know of any auth providers which use this frankly, but I think calling it like below is the reasonable thing to do. Is there a particular reason you think it should not be called?
There was a problem hiding this comment.
We talked a bit more about this and the reason we can't just call it here is that we don't yet have the access token (the client hasn't acknowledged that they've been able to use the dehydrated device).
It seems like we would ideally want to call this at the end of the call to /restore_device, but we no longer have the callback at that point. Will need to think about what the best option is here.
|
I think we've decided the implementation in #8380 is a bit less invasive. Shall we close this? |
|
replaced by 8380 |
implements matrix-org/matrix-spec-proposals#2697