-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Implement MSC3356 to support additional fields in the OpenID user info #10384
base: develop
Are you sure you want to change the base?
Implement MSC3356 to support additional fields in the OpenID user info #10384
Conversation
…enty the display name an the user's effective power levels)
I believe that this would need an MSC to accompany it since it is a specified endpoint? (In which case we wouldn't need to have any config options and could just include them, most likely.) |
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 believe that this would need an MSC to accompany it since it is a specified endpoint? (In which case we wouldn't need to have any config options and could just include them, most likely.)
Yeah, there's not much point in supporting extra fields for Synapses deployed on the open federation unless the spec is extended to document the additional fields.
That said, there's probably a usecase for custom fields in private federations - but in that case, I'd expect the extension to happen via a Synapse module (see https://matrix-org.github.io/synapse/latest/modules.html) rather than an eclectic mix of configuration options.
@jkanefendt: could describe your usecase here, so we can suggest how to proceed?
I finally found the time to create a MSC with a brief description and usecase - see https://github.com/matrix-org/matrix-doc/blob/4c415fb7bc2d991a4515820d8c4fda75e98ce94e/proposals/3356-add-openid-userinfo-fields.md |
…add-openid-userinfo-fields
… a fixed, statically configured set. Extend the set of available fields by the user's avatar url.
@jkanefendt That MSC will need some unstable prefixes defined (or the MSC otherwise needs to be merged) before we can implement it in Synapse. See here for an example of defining unstable prefixes. You would need to add an unstable prefix to each of the new key names in the OpenID response. It also appears that there are some unaddressed comments on the MSC, which addressing will help move the MSC forwards 🙂 |
Thanks for your feedback @anoadragon453 . I'm going to add the unstable prefixes ASAP. |
I think that's an excellent addition. And since we're on the topic of implementing additional features as they come into the MSC, don't be afraid to break up the feature into multiple PRs, especially for self-contained changes like specifying which fields to return. It can help make review easier and get your code merged quicker. Looking forward to the unstable prefixes. Do poke on the MSC PR if you need any further clarifications on how to add them. |
All these points have been covered in MSC3356 by now. |
Sorry, I got my numbers mixed up. 3356 versus 3556. |
…ental_features.msc3356_enabled`
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.
Generally this looks great to me, though I have a few nits it would be nice to clean up.
async def on_openid_userinfo( | ||
self, token: str | ||
) -> Optional[Tuple[str, Optional[List[str]]]]: |
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.
please could you add a docstring documenting what this returns?
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.
async def get_user_id_and_userinfo_fields_for_open_id_token( | ||
self, token: str, ts_now_ms: int | ||
) -> Optional[str]: | ||
def get_user_id_for_token_txn(txn: LoggingTransaction) -> Optional[str]: | ||
) -> Optional[Tuple[str, Optional[List[str]]]]: |
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.
again, please can you give this a docstring.
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.
@@ -0,0 +1 @@ | |||
ALTER TABLE open_id_tokens ADD COLUMN userinfo_fields TEXT; |
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.
please could you add a sql comment describing what this column contains.
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.
room_state = await self.hs.get_state_handler().get_current_state( | ||
room.room_id | ||
) |
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.
please can you give this event_type
and state_key
arguments. Pulling out the entire room state for a large room is quite expensive.
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.
Solved in 29664b1
stripped_content = copy.deepcopy(room_power_levels.content) | ||
stripped_content["users"] = { | ||
k: v for k, v in stripped_content["users"].items() if k == user_id | ||
} | ||
power_levels[room.room_id] = stripped_content |
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 don't think I have strong feelings on this. I think the current behaviour is probably fine. It would be nice if the MSC made the behaviour here explicit though.
One other thing: it would be really nice to see some tests for this stuff, especially the power-levels stuff which looks fiddly. It might be best to wait for more progress on the MSC before putting in too much work in that direction though. |
…add-openid-userinfo-fields
Hi again @jkanefendt. Just checking in to see if you're able to continue with the suggested changes? It'd be good to see this PR finished up :) |
Hi @anoadragon453. I'm quite busy right now, i hope i'll find the time to add the requested changes and documentation in June! |
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
…_fields_for_open_id_token (storage.databases.main.openid.OpenIdStore) is not optional any more
…d_token (synapse.storage.databases.main.openid)
Hi @jkanefendt, thank you for updating this PR. Looking at MSC3356, there have been concerns raised about whether the design is the right approach. I'm a little hesitant to merge this PR before that opinion in engaged, even behind an experimental flag. Could you respond with your thoughts on the MSC? |
Taking this out of the review queue until the discussions on the MSC are resolved. |
Add option to include additional fields in the OpenID user info (currently the user's display name an effective power levels).
This should simplify room-based access control in third-party widgets. Currently, joined rooms and power levels can only be determined via Admin-API.
See MSC3356.
Signed-off-by: Johannes Kanefendt johannes.kanefendt@krzn.de