Widget OpenID reauth implementation #2781
Conversation
Covers the minimum of element-hq/element-web#7153 This does not handling automatically accepting/blocking widgets yet, however. This could lead to dialog irritation.
turt2live
changed the title
There was a problem hiding this comment.
I have read through your proposal snippet and the original issue. This is my first time looking at the code related to widgets, but I am hoping to understand it better through this review. 😄
|
|
||
| // True to put the toggle in front of the label | ||
| // Default false. | ||
| toggleInFront: PropTypes.bool, |
There was a problem hiding this comment.
Why do we sometimes want the opposite order?
There was a problem hiding this comment.
Usually the toggle is at the end of the label, however in a dialog this doesn't make much sense to the user. This is the first instance of needing to do this, and it seems easiest to just put a boolean on it.
Everywhere else:
Widget dialog:
There was a problem hiding this comment.
Hmm, well, technically it's fine. I'd suggest asking Nad if he would prefer only having one layout of toggles or if he agrees it seems better reversed as you've done it here.
There was a problem hiding this comment.
Summarizing the discussion from earlier today: We'll take care of this in element-hq/element-web#7566
| throw new Error("No matching user widget to form security key"); | ||
| } | ||
|
|
||
| widgetLocation = userWidget.sender; |
There was a problem hiding this comment.
Is the sender of a user widget always yourself? (That's what it seems to be for stickerpicker widget, at least...)
There was a problem hiding this comment.
yes, it has to be. They are stored in account data and other places enforce this assumption.
Fixes element-hq/element-web#7153
The proposal for this is part of https://github.com/matrix-org/matrix-doc/issues/1286. The relevant snippet (and therefore draft) is available here: https://gist.github.com/turt2live/669bbffe882c8541f057daeb29e18b86
As a proof of concept, I've also created a Dimension widget which does nothing more than report your user ID back to you - all without using the
scalar_tokenprovided in the query string, and without you having to configure your client to point at a Dimension instance.Testing procedure:
/devtools, create anim.vector.modular.widgetsstate event with state keyreauthwidgetand content of:{ "type": "customwidget", "url": "https://dimension.t2bot.io/widgets/reauth", "name": "OpenID Reauth Demo", "data": {}, "id": "reauthwidget", "waitForIframeLoad": true, "creatorUserId": "@travis:dev.t2host.io" }creatorUserIdto be your user ID.To repeat the process, refresh the page. There's currently an unrelated bug that prevents reloading the widget from being enough to unstick the state: the whole page needs to be refreshed. This will be addressed in a different PR (#2799).
Source for the widget: https://github.com/turt2live/matrix-dimension/blob/master/web/app/widget-wrappers/reauth-example/reauth-example.component.ts
This is being PR'd as a community member: