Filling in discourse_username when not using DiscourseConnect

Support WordPress
1

This was a question on an old github issue, which is more easily tracked here on meta

https://github.com/discourse/wp-discourse/issues/237

From @mattdm:

We’re using OpenID for login, and it seems like that option is only available when using DiscourseConnect. Is there another way? Filling them in manually is pretty annoying.

We do allow users to edit their email address (distinct from the SSO) on the Discourse sites, but the user id is guaranteed to be the same.

My initial response (questions are still outstanding)

Hey @mattdm, could you clarify a few things:

  1. A user’s email may be different between their accounts on wordpress and discourse?
  2. What do you mean that “the user id is guaranteed to be the same.”? Which user id are we talking about?
2 Likes
2

Oh, sorry — I was sure I answered that before but I guess… I didn’t? Maybe I just thought about it! Anyway:

  1. The email is initially synced from the SSO for both WordPress and Discourse. However, due to popular demand, we allow people to change that email on Discourse. (It turns out to be frequent to want Discourse notifications going somewhere other than the email associated directly with the login.) It is also possible to change the email address on Wordpress, but I don’t know of anyone who does that, or even if outgoing email on that instance works.

  2. By “user id”, I meant “username”. The username is always[1] taken from the SSO for both Discourse and Wordpress and can’t be changed by the user in either case. For some reason unknown to me but which probably made sense at the time, this is nickname on our SSO side; this is mapped to oauth2 json username path.

  1. Actually it turns out that there are few accounts like my own which happen to have been set up before we had the SSO, and they’re wrong — I’m “Matthew Miller” instead of mattdm. But we could clean that up. ↩︎

3

hm ok, so effectively

  1. There would be a subset of your users with different emails on wordpress and discourse.
  2. Your username is gauranteed to be the same as its provided by your identity provider for both wordpress and discourse

If we were to decouple the WP Discourse user webhook from the DiscourseConnect functionality (possible), then user matching would occur on the basis of email, not username. Your situation is somewhat specific to your identity setup.

I think this case that’s better handled via custom code on your wordpress. What you want is something like this:

function update_discourse_username( $user_login, $user ) {
    update_user_meta( $user->ID, 'discourse_username', $user_login );
}
add_action( 'wp_login', 'update_discourse_username', 10, 2);

Basically, just assign the discourse_username meta field as the WP username after login, as they’re guaranteed to be the same. Note that “user_login” is what the “username” is sometimes called in wordpress code.

4

Coming back to this several years later. :slight_smile:

Sometime along the way, we changed so email addresses are force-synced from our (oauth2) SSO. So, we should be able to match that way. (And, even if there is for some reason a mismatch, there shouldn’t be a case where an email belongs to someone else, so worst-case that’d just fail, right?)

Any chance of making the WP Discourse user webhook Just Work?

Failing that… I’m not a WP expert, and our WP is hosted, so I’m not sure we have an easy option of customizing the plugin.

CC @jwf

5

Ok, so just to clarify

This is no longer the case?

Just a note that it does currently work. You’re asking for a new feature :slight_smile:

Moreover, you’re asking for a new feature that has to be considered quite carefully. I know I said it was possible a few years ago, however I’m currently slightly wary of doing this as a core feature of the plugin, as such a feature would have to assume that email addresses are properly validated on Wordpress, which is not necessarily a safe assumption.

That (Wordpress email validation) is the responsibility of the site administrator, however a principle of open source development is to avoid creating something that will cause bad outcomes in a subset (even a small subset) of cases, assuming you have no control over the environment. This problem is still there, but mitigated, when it’s just limited to DiscourseConnect.

I’ll consider it more closely and get back to you later this week.

1 Like
6

If the email matching is too complicated, I feel like “Discourse usernames always match WordPress (and vice versa)” can’t be that uncommon.

Even if someone doesn’t have an SSO system which assumes a unique username, there surely must be many smaller sites with, say, dozens of WordPress users where this is true by convention.

7

There’s sort of an existing solution for this. Discourse can be configured to be the DiscourseConnect provider for WordPress (the opposite of the usual configuration). It’s easy to setup. When enabled, there’s an optional setting that allows WordPress/Discourse accounts to be synced based on the user’s email address.

There’s even a link added to the user’s profile page:

image
image1110×187 11.8 KB

(edit: can an image be captioned without ai?)

Testing it now, clicking the link on the profile page is not filling in the Discourse Username field. It should. Clicking the “Log in with Discourse” link that can be added to the login page does cause the Discourse Username field to be automatically updated.

I think the point of syncing accounts is to update the Discourse Username field in a secure way, so it’s probably worth looking at what’s going on with this. It also looks like there’s an issue where accounts that have an “unverified” email address on WordPress are allowed to sync their accounts with Discourse. That probably shouldn’t be allowed by default.

For your case, you might not want to allow users to login to WordPress via Discourse. It should be possible to just use the link on the profile page to allow users to sync their accounts so that their Discourse username field gets automatically filled in. You shouldn’t have to enable logging into WordPress via Discourse for this to work.

A possible downside of this approach is that users will have to initiate it. It wouldn’t provide a button that admins could click to get a user’s Discourse username.

8

That seems silly. We have a centralized SSO. We should not have to configure some of our services to use other random services as the auth provider just to get them to work together. That’s a route to madness.

9

Don’t get thrown off by the name (DiscourseConnect). If the feature I described was working as it should, it would just be a way for a WordPress user to confirm that they had a Discourse account with a matching email address and get their Discourse username automatically filled in on WordPress. It wouldn’t affect your site’s auth system.

10

There will never be a Wordpress username to Discourse username matching identity mechanism in the core plugin, even behind a setting. The only possibility in this context is email matching. I’ve decided to add email matching as a fallback mechanism to the user webhook. It’ll be in the next version, which will come within a few weeks.

1 Like
11

Just to close the loop on this, the latest version of the plugin 2.5.4 included various updates to Webhooks, including removing the DiscourseConnect requirement for the “Match Users by Email” setting. See further

1 Like
12

I think this will solve our problem, at least in 99% of cases. Thank you!!!

@jwf FYI I went ahead and turned this on our site.

2 Likes
13

Awesome, I will keep an eye on it for future topics with the plugin.

2 Likes