Hi, I am integrating Discourse with a community site where members can already “block” each other. So when a member of my site SSO’s into Discourse, I’d like to also pass the list of blocked external_id values. These can just go in the “Muted users” field, I guess, on the Discourse side…
And if not, then to accomplish this functionality, it seems like I’ll have to set up a webhook and when I get a user_logged_in event from the webhook, I can then use the Discourse API to pass the list of muted users… is that correct? (And if so: where is that call in the API? I couldn’t find it!)
Yeah this sounds somewhat similar to other extensions SSO already has. It is pretty rare to need this so I am on the fence about adding this to the protocol or not.
The webhook will work, you would get called on login, then you can make a second call to discourse to synchronize the list via our API.
Hi Sam, yeah, for my immediate problem, I’ll just response to the webhook user_logged_in event-- no problem. Thanks for that.
And I understand where you are coming from with regards to what can be passed on SSO. As I continue to deeply integrate Discourse with my site, I’m understanding more about how y’all chose to implement SSO. It works well now, but I actually think it might be interesting to consolidate all the “SSO overrides…” checkboxes into one sort of general checkbox where it’s like “SSO manages all user attributes” (or something like that).
The idea would be that if I turn on this global SSO checkbox, the only thing I have to be consistent with is the external_id: promising Discourse that it will always be unique, always identify the same user and never change. Once that’s in place, I could pass all the fields I wanted with the SSO request and load the user completely from my database.
about adding this to the protocol or not.