Email field not populated on SSO User?

sso
1

We are successfully creating Discourse users via SSO, using a custom endpoint on our IdentityServer3 IdP (using an approach extended from this idea)

We are passing in an email value in the SSO payload (I think it is mandatory, so implicit in the fact what we are doing works).

In the admin backend of Discourse, if I look on an individual user record the “Primary Email” field contains the email we passed in via SSO.

BUT, if I look at the user list at /admin/users/list/active the email column is empty for those users, and if I query via the API by GET /admin/users/list/active.json those records also have nothing in the email field.

Is this a bug, or have we missed something we should be doing?

UPDATE

The webhook events that are fired for user_created and user_loggedin contain a correctly-populated email field in the payload

UPDATE 2
Querying via GET /admin/users/{id}/{username}.json shows the email in [single_sign_on_record][external_email]

2

You should include show_email in URL query string /admin/users/list/active.json?show_emails=true.

4 Likes
3

Thanks @vinothkannans that fixed it, is it safe to include that parameter on every call to GET (regardless of endpoint and relevance), or do I need to make sure I only add it to the endpoints that use it?

Also is it documented somewhere?

DUH my bad - it’s in the docs

4

You can ignore that parameter when the email is not required. If you’re going call it often then you should have local cache/table for emails. When you use show_email param it will create a staff action “check email” in /admin/logs/staff_action_logs.

1 Like
5

Thanks - that’s a subtlety we will have to build in to our provisioning logic.

The issues are external to Discourse, but for completeness - on each user login we are checking for group membership based on data in our CRM. Because we are forcing all users to be registered on our SSO, in most cases we will already have a matching CRM record that we can access via the SSO identity key. There is a possible edge case where we have to query CRM by email, but as I think the user_login webhook event contains email always we may be able to avoid calling the api with show_emails=true

Going further I notice the endpoint for a specific user does not have an option to accept the show_emails parameter (or ignores it if you do), is that worth a feature request?

1 Like
6

You can send group membership as part of the SSO load. If I understand your situation that’s what your want to do and you won’t need to check the user record.

1 Like
7

I may well add that later, but for a number of reasons, including:

  • group membership is volatile (e.g. existing customer purchases a new training programme that has an associated group/category)
  • how our different systems are (or are not) coupled
  • subtle differences in our SSO registration / authentication flow depending on whether user is creating an SSO account with username/password or authenticating to our SSO using a federated identity like Google

the safest and simplest thing to do is to check on login each time.

However because the email field IS populated in the user_login webhook I won’t need to query the Discourse user for email (that was a bit of a side track). I’m still going to have to query the user to add them to a group because that endpoint needs usernames not ids, and for a whole set of reasons I won’t bore you with we aren’t tracking the Discourse username externally