Is this the only thing that this setting does?
It’s named and described in WP quire vaguely I feel so I was wondering what else it might do?
Regarding this,
what if a user already exists inside Wordpress and Discourse. How do i merge / connect their profiles?
Technically, what it does is make a call to the Discourse sync_sso route and passed their data (WordPress user_id, username, name, email…) to Discourse immediately after they login to WordPress. Details about the sync_sso route are here: Sync DiscourseConnect user data with the sync_sso route.
The only side effect of this that I’m aware of for WordPress users who have never visited the Discourse site is that they will start receiving digest emails from Discourse.
This is why you want to encourage your Discourse users to register on WordPress with the same email address as they are using on Discourse. As long as the email addresses match, they will be logged into the correct Discourse account. This is assuming you take care of the issue with email verification that we discussed in previous posts.
It’s likely that you’re going to end up with some users signing up on WordPress with different email addresses than they’ve used on Discourse. For that case, a new Discourse account will get created for them, using the WordPress email address. You’ll need to manually merge the old Discourse account into the new Discourse account: Merge User Accounts.
3 Likes
What happens if we have to manually update a users email in Wordpress. Does their Discourse email also get updated if this setting is enabled
1 Like
Updating a user from their WordPress profile page doesn’t trigger the call to sync_sso. It probably should do that though. For now, you’ll need to ask them to log out of WordPress, then log back into WordPress. I don’t believe it’s possible for an admin to logout a WordPress user from their profile page.
If you want to keep emails and/or usernames synced between WordPress and Discourse, enable these Discourse settings:
auth overrides emailauth overrides username
1 Like
Thank you Simon. I think this is the process I will go with after considering everything:
- Export users from Discourse
- Activate Discourse Connect
- Import and create those users in Wordpress and mark their emails as verified in WP
- When these users login (via custom login page) they have to reset their password
- Somehow force only this segment of users to change their password after they enter their email (and system realizes they are apart of this segment)
- OR just Show message on login page: “if you are logging in after [date] you must RESET your password”
- Access should work!
As for new sign-ups that come in, I will need to figure out a way to verify the emails. I’ll probably just email them their passwords.
I also noticed that even if the “Email Address Verified” setting is not selected in the Wordpress profile, the user is still able to SSO onto discourse. They have to confirm their email regardless the first time they enter Discourse though. Which is good.
Do these settings have any side effects?
1 Like
Yes, that’s the way it’s intended to work. That’s not much of a barrier for most users. The issue you need to be aware of is that if the email address is not marked as verified on WordPress, Discourse will not match WordPress users to Discourse users based on their email address the first time they login to Discourse via DiscourseConnect. As long as you figure out how to mark the email addresses of your imported users as verified, that won’t cause an issue. If you don’t mark them as verified, it’s going to be a hassle to sort things out.
If enabled, they prevent users from changing their username or email address on Discourse.
1 Like
yea I was testing a ton and I realized this. I am just going to write a custom script that marks all users who I import as verified.
Thanks for clarifying!
1 Like
Is it okay to keep the verbose /logs on forever?
Will this negatively impact performance?
I’ve seen cases where they’ve been left on forever. I don’t believe it has any meaningful impact on performance. It just clutters up your logs if you’re trying to debug an issue that isn’t related to DiscourseConnect.
2 Likes
Everything has been working great so far!
One small thing I am noticing is that whatever path I input into this field:
becomes the default WordPress login page.
For example, if I try now to go to /wp-admin which is what I would previously use to login as admin, it redirects me to /login/forum
Ideally, it would only redirect to this when someone clicks the login button from the discourse forum.
I’m wondering if this is normal behavior and if it is a bad thing for it to function like this.
That is the expected behaviour. The “Path to your Login Page” option is used to override the default WordPress login path. It does that by hooking into the WordPress login_url filter.
It doesn’t remove the default login route at /wp-login.php, so you can still go directly to that URL by entering it into your browser’s address bar. Instead of going to /wp-admin, go to /wp-login.php to use the default login page.
I can think of a way that the plugin could be updated to only redirect to the “Path to your Login Page” path for logging into Discourse, but that change would take a bit of work.
4 Likes
No worries. Just a small thing. Thanks for the insights!
1 Like
Hey @simon I am seeing the following errors in my log and am wondering what they mean and how to address them. Noticed these after a user said they are getting an error when trying to log in.
-
(google_oauth2) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected
-
Authentication failure! request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) Authentication failure! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, must pass either a
code(via URL or by anfbsr_XXXsigned request cookie)
It’s worth noting that these errors are not common. Most logs seem to be working successfully:
just received this screenshot from the user:
He said " There is no email. As soon as you click on the sign-up link, you are presented with the following page…
"
when I click the login/signup link (on incognito), it works for me.
Here is the URL to our forum for reference: forum.projectvanlife.com
I am assuming the entries starting with “Verbose SSO log” are showing successful logins.
For the “google_oauth2”, “OAuth::Unauthorized”, and “facebook” errors, I’m not sure what is going on. Was your Discourse site previously configured to allow users to login via Google and Facebook? If so, they won’t be able to login to the site with those methods now that DiscourseConnect is enabled. Maybe try disabling Google and Facebook logins from your Discourse settings page.
For users who report errors with logging in, try to find a verbose SSO log error message that is associated with the user’s login attempt. Then see if the error matches any of the issues that are described in this topic: Debug and fixing common DiscourseConnect issues.
The URL shown in the browser’s address bar is https://projectvanlife.com/login/forum/javascript%3Avoid(0.
I’m assuming some of the javascript is being truncated and it’s actually intended to decode to javascript:void(0). I’m not sure where that would be coming from. Possibly from one of the user’s browser extensions. Try asking them to disable their browser extensions, or to try logging in from an incognito window.
Edit: @Sami_Syed the javascript:void(0) code is being appended to the path when the login page’s “Sign Up” link is clicked. That link’s href element is: "javascript%3Avoid(0)"
I guess that what it’s being used for is to have the signup form on the same path as the login form. Something is going wrong with it though. Do you know if this was working correctly before DiscourseConnect was enabled?
If the plugin that’s used for the login/signup forms has an option to have the signup form appear on a separate page, enabling that should work as a quick fix for the issue.
I’m going to be offline for most of today, but can try to help with this later on if you’re stuck.
Edit: I was puzzled about this, so had another look. The “Register” tab on the login form works without issues. The “Sign up” link has the issue I described above:
So the quick fix for the issue is to just remove the signup link.
2 Likes
This is correct.
Yes, this was enabled. The question is though, how are they even able to trigger a login through FB or Google now? Our current login page does not have that feature.
Or is this error coming up for those who signed up originally using G or FB and now they are trying to login but it won’t work?
And if that’s the case how can I resolve it.
As I see, it’s because I didn’t set a correct llink there. Oops. good catch and thank you!
I don’t know what could be triggering it. Maybe the URL to the auth provider was cached by the user’s browsers. That’s just a guess though.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.