-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC1961: Integration manager authentication APIs #1961
Conversation
|
||
#### POST `/_matrix/integrations/v1/account/logout` | ||
|
||
Logs the token out, rendering it useless for future requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this say that all tokens associated with the user should be logged out, not just the token this request was made with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope, just the token that was requested. This MSC does not propose an equivalent for /logout/all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the follow-up question is then; should IM's have a /account/deactivate
? When a user deactivates their account, it would be good for clients to pass that information to the IM, to tell it that this user will no longer exist and that all possible tokens and user information should be deleted. Or should this be a different MSC?
Pinging @lampholder for the privacy side re IM's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd make that a separate MSC. I'm trying to keep these integration manager MSCs tightly scoped to avoid creeping features, given they are all trying to introduce a whole new API surface. This particular MSC is scoped to just authentication: deactivation is a feature which affects authentication but is not required for authentication. For instance, an integration manager could just delete everything after the last token is logged out. Similarly, there is no API for listing how many tokens you have assigned to you (and logging them out).
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short, sweet and sane.
All good here 👍 |
I'm not familiar with the integrations API as it stands, but no objections from me here. @mscbot reviewed |
Process question: will these MSCs land separately or only once the full "integrations api" MSC lands? I'm comfortable with saying these APIs look fine, but I can equally imagine that after we land a bunch of integration API related MSCs it becomes clear that already MSCed APIs need to change. Maybe we basically say: "this MSC is part of the unstable integration API module" and then the final MSC basically says "stabilise the integration API module"? |
ftr, there isn't one. This is part 1 of many to make it a thing. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
As per MSC1961, add to the whitelisted integrations_widget_urls the new paths. This allows us to switch Scalar over to use the new path as default. Note, the legacy "scalar-staging.riot.im" is these days just a redirect to scalar-staging.vector.im, so there is no addition for that. It still needs Riot side whitelisting though for existing widgets. Refs: matrix-org/matrix-spec-proposals#1961
As per MSC1961, add to the whitelisted integrations_widget_urls the new paths. This allows us to switch Scalar over to use the new path as default. Note, the legacy "scalar-staging.riot.im" is these days just a redirect to scalar-staging.vector.im, so there is no addition for that. It still needs Riot side whitelisting though for existing widgets. Refs: matrix-org/matrix-spec-proposals#1961
As per MSC1961, add to the whitelisted integrations_widget_urls the new paths. This allows us to switch Scalar over to use the new path as default. Note, the legacy "scalar-staging.riot.im" is these days just a redirect to scalar-staging.vector.im, so there is no addition for that. It still needs Riot side whitelisting though for existing widgets. Refs: matrix-org/matrix-spec-proposals#1961 Signed-off-by: Jason Robinson <jasonr@matrix.org>
As per MSC1961, add to the whitelisted integrations_widget_urls the new paths. This allows us to switch Scalar over to use the new path as default. Note, the legacy "scalar-staging.riot.im" is these days just a redirect to scalar-staging.vector.im, so there is no addition for that. It still needs Riot side whitelisting though for existing widgets. Refs: matrix-org/matrix-spec-proposals#1961 Signed-off-by: Jason Robinson <jasonr@matrix.org>
This has now been implemented and deployed for Scalar as well. |
Rendered
Upstream proposal: MSC1956 - Integrations API
Discussion room: #msc-integrations-api:t2bot.io
Implementation (IM): turt2live/matrix-dimension@57d585d
Implementation (Client): Incomplete
This is being contributed under the hat of "author of Dimension":