When Discourse is an identity provider, does it save the external user IDs?

dev
,
1

I’m using Discourse as an identity provider for my rails application (you sign into my rails app with your discourse login; not the other way around). I’d like to add a link on user profile pages in Discourse to take you to their respective profile on my rails app. In order to do that, Discourse would need to know their user id in my rails application/database.

I know DiscourseConnect saves ‘external_id’ when you do it the other way round (sign into discourse with some other login). But does it save anything when it’s this way round?

If not, any advice for storing it?

1 Like
2

It doesn’t, so you’ll need something custom.

I wonder if it would make more sense to handle this in your Rails app, since it knows the Discourse ID of a user?

You could set up a route like /profile-by-discourse-id/:discourse_id which looks up the relevant user based on the discourse ID and then redirects to the user’s profile in the rails app.

1 Like
3

Thanks @david. Funny enough that’s exactly what I did for linking in the other direction (from my rails app user profiles to discourse user profiles) via this discourse plugin (/user-by-id/123/summary) since my rails app stores the discourse user id instead of the username (since usernames can change).

That solution would work in the other direction except for the fact that not all forum users have user profiles in my rails app. A rails user is only created once the discourse user ‘joins’ the organisation, whereas the discourse forum can have non-members in it.

So I suppose my two options are:

A) Create a JavaScript plugin that sends an ajax request to my rails app to determine whether the discourse user is also a user in the rails app, and if so, render a link; or

B) At the point when the rails app user is created and linked to the discourse user, in addition to storing the discourse user id in the rails app database, somehow store the rails user id in the discourse user profile (e.g. as a custom user field).

I feel like (B) is the better solution (provided the custom user field is not changeable except by admins), though I’m not familiar with custom fields or whether they’re accessible via API.

EDIT: Now I remember from the last time I looked into this: the problem is that custom user fields are editable by the user, which makes them a bad place to store a system-generated reference like this :confused: