I’m helping with an instance with wp-discourse and a day or to ago (I think when they upgraded to beta6) SSO logins started to fail. They seem to be failing with
{:primary_email=>"has already been taken"}
so somehow it’s not connecting existing accounts correctly?
Verbose SSO log: Record was invalid: User
{:primary_email=>"has already been taken"}
Attributes:
{"admin"=>false, "moderator"=>false, "locale"=>nil, "name"=>"Jay Pfaffamn", "title"=>nil, "username"=>"jaypfaffman1"}
SSO Diagnostics:
add_groups:
admin:
moderator:
avatar_force_update: false
avatar_url: https://secure.gravatar.com/avatar/b4369076dc8ab119a551de8dfacfac42?s=96&d=404&r=g
bio:
card_background_url:
email: jay@literatecomputing.com
external_id: 16719
groups:
locale:
locale_force_update:
name: Jay Pfaffamn
nonce: bc8ed4--------------
profile_background_url:
remove_groups:
require_activation: true
return_sso_url:
suppress_welcome_message:
title:
username: jaypfaffman
website:
Rendering session/sso_login.html.erb within layouts/no_ember
Rendered session/sso_login.html.erb within layouts/no_ember (0.3ms)
Rendered layouts/_head.html.erb (3.9ms)
Rendered common/_discourse_stylesheet.html.erb (0.2ms)
Rendered application/_header.html.erb (0.2ms)
Completed 500 Internal Server Error in 31ms (Views: 3.1ms | ActiveRecord: 12.5ms)
They claim that nothing has happened on the WP side lately.
Matching up by email will never happen if you have require_activation: true. I don’t think anything has changed on the Discourse side recently… the last change to that logic was 7 months ago.
My suspicion was the new security thing (that I can’t quite remember what it was now) caused the problem. They had http:// rather than https:// for the SSO_URL, even though the site was https (and I guess redirecting to https so it still worked). But that doesn’t seem to make sense either.
No. I checked a couple (of the SingleSignOnRecords)and it seems that they aren’t getting created? (Users are fine and created)
I tried creating a new user, as I was concerned that it might actually be true that I’d created a user on the discourse side that was causing a problem.
Looks like the last two created was one for the site owner yesterday (probably just before he did an upgrade at the web console?) and another from a new user today. “Seen” for that user is not set (on /admin/users).
username there is pfaffman-test21 but username is pfaffman-test2
Yes. And I can confirm that another user also has 1 appended to the username.
Maybe the problem is require_activation: true? WP does do email validation, so it’s safe to turn that off. Maybe they did some WP change and took out whatever was settgin require_activation: false before?
The require_activation parameter is set by the WP Discourse plugin if a site isn’t using the default WordPress registration system. When it is set, WordPress users are not matched to Discourse users by their email address. Existing users who already have an SSO record associated with them should have no problem logging in though. New users should also be able to create accounts without any problem.
Are all SSO logins failing on the site? Are you able to try creating a new account on WordPress and then logging into Discourse via SSO?
OK. Manually creating the SignleSignOnRecord makes the login work.
It does seem clear that something changed on the WP side?
And that’s been the case for at least seven months.
I think I’ve seen that this can be overridden by adding. . . something . . . to functions.php?
I think that it’s true that no users can log in, though I don’t have very good data.
I don’t see a plugin that is obviously a non-standard WordPress registration system. Could something else be triggering that as a false-positive?
Here are some:
“Cimy User Manager”
" Eonet Manual User Approve"
new user approve
ONTRApages – ONTRApages for WordPress allows ONTRAPORT & ONTRApages Premium users to connect to their accounts and easily host their landing pages on their own WordPress sites
There haven’t been any recent changes to the WP Discourse SSO login code.
If manually creating the SSO record is fixing the issue, then the problem seems to be that the user IDs that are being sent from WordPress as the external_id don’t match the external IDs on the user’s Discourse SSO record. This can happen if a user’s account is deleted and then recreated on the WordPress site. I wouldn’t expect it to affect all users on a site though.
Another case the will cause problems when the require_activation parameter is set to true is for users who were created on Discourse prior to SSO being implemented. This would also affect users that were created on Discourse with the rake admin:create task.
If a site is using the default WordPress registration system, users will be registering through a form that looks like this:
You should try to confirm if other users on the site are able to login via SSO. The easiest way to do that would be to create a new account on the WordPress site with an email address that you have not yet used on the Discourse site. If you are able to login with a new account, that will make it easier to figure out what’s causing the problem.
Thanks very much. I did a couple searches for require_activation and couldn’t find the “how to turn off…”.
When the sun comes up in WordPress guys side of the world hopefully they can resolve this. I don’t know whether the registration system changed recently and the site owner doesn’t seem to know either.
I presume this resolves this, I’ll report back when I know more.
I’ve avoided writing a howto topic about this, because it’s generally a bad idea. The intention behind the discourse_email_verification filter is that it will be only used when another email verification system is in place.
There are some upcoming changes to the WP Discourse plugin that will allow WordPress admins to mark an email address as valid to handle email verification on a per-user basis. That should be good enough to deal with most cases.
That makes sense. I mostly think that even with a howto, it’s hard enough to fuss with the code to turn off email verification that it’s unlikely that someone will do it when they shouldn’t. But I could definitely be wrong.
This system emails a plain-text password (!) both when the account is created and when you want to reset the password. While that’s a horrible idea, it does validate the email. I suppose the place to put that hook is to have it run when the person successfully logs in on the WP side.
I figured it’d be worthwhile to jump in here and ask whether the upcoming changes could be manually added to the current version of the WP-Discourse plugin so we can get rid of this problem?
On the WordPress side the registration process has not changed in any way since November 2017. We use the EONet Manual User Approve plugin, which allows users to register but not login, and on manual approval by an admin, the user is then made active and issued a password they can either continue to use, or change on first login.
(I would also like to point out that the normal WordPress user system is still in use, the only change made by the EONet plugin is for the initial activation. All users that register are 100% normal WordPress users.)
I have hooked into the approval process so that a user is only created in Discourse once their account is approved, so email verification should not be an issue. If there’s a way to specify that require_activation not be turned on then that sounds like the way to solve this.
There’ve been a chunk of WordPress updates over the past few days, but nothing that should’ve impacted anything remotely related to user registration or the Discourse link. The SSO was even working fine after we went HTTPS on the WordPress side about a month ago. There was also the forced PHP 7.2 upgrade on WPEngine a couple weeks back, but as I say there have been recent group discussions held on BFP where there were no issues with registrations or logins…
Well, you sound like someone who knows where to stick that filter! I’m several hours in to this little project to get this far. I hope that you can stick in the code and we’re back in business. (And then maybe I’ll get you to get my site up to date with WP and WooCommerce! )
Hi Jay, I’ve put in the filter and now testing a new registration and I’ll post an update here shortly. Kind of you to think of me for your WordPress work!
Well I’m ecstatic to report that adding the filter worked to get a new user into Discourse without throwing any errors, so thanks to Simon, Jay and David for all your help on this!
For any future visitors to this thread, the filter that fixed the issue was
add_filter( 'discourse_email_verification', 'wpdc_custom_discourse_email_verification', 10, 2 );
function wpdc_custom_discourse_email_verification( $require_activation, $user_id ) {
if (/* some condition */) {
$require_activation = false;
}
return $require_activation;
}
)