Possible bug with 'Redirect After Discourse Login' field


(Andrew Pautler) #1

I’ve been chatting with Arpit about the some issues with the redirect URL after you login. Here is a little context:

Our forum is connected to WordPress via the WP Discourse forum. When you try to go to the forum before logging in, it redirects you to the WordPress login page (which is correct). After you login though, it redirects you to the WordPress homepage vs. the page I have set in the ‘Redirect After Discourse Login’ (see here: Screen Shot 2017-05-17 at 7.20.59 AM.png).

Arpit referenced this code (wp-discourse/discourse-sso.php at 58546613b97497e9698b1a7110bdbb6f76baa2b8 · discourse/wp-discourse · GitHub) and said:

It seems like home_url(’/dashboard’) is not getting parsed correctly. This might be a bug in wp-discourse plugin, not sure though.

@Simon_Cossar, he said you might be able to take a look.

Ideally I’d have the user redirect back to the forum homepage after coming to the login page from that URL, but it doesn’t appear the ‘Redirect After Discourse Login’ allows external links. If that is not possible, I’d like to at least redirect the user to the WordPress page I set in the ‘Redirect After Discourse Login’ field.


(Simon Cossar) #2

The way it’s intended to work is that when a user clicks on the login link on the forum, they should be redirected back to the forum. When a user logs in directly from the WordPress site, if ‘Create Discourse User on Login’ is enabled, they should be redirected to the URL that’s set in the ‘Redirect After Discourse Login’ setting.

I’ve tried it in my development environment with ‘/dashboard’ set as the ‘Redirect After Discourse Login’ URL and it’s working correctly there.

I have seen problems with the SSO login redirects when another plugin is hooking into the WordPress login_redirect. Paid Memberships Pro is an example of a plugin that causes a problem with the login redirect. If this is the case, and we can figure out which plugin is causing the problem, there is probably a way to work around it.


(Andrew Pautler) #3

So the way we have the integration setup now, whenever you try to go to the forum and are not logged in, it redirects you back to the WordPress login page. This means we are using the WordPress login and it should redirect you back to the page setup in ‘Redirect After Discourse Login’ field. Right now it isn’t doing that. Ideally we’d put the discourse forum URL in this field, so if they come from the forum to the WP login it redirects them back to the forum vs. the WP homepage. This currently isn’t possible because the ‘Redirect After Discourse Login’ field doesn’t allow for external URLs. Is that intentional?

If we can’t link them back to Discourse, I’d like to at least direct them to the appropriate page on WordPress. We are using a membership plugin called MemberPress. It is hooking into the WordPress setup and making the login URL /login on a custom page vs. the default WordPress login. I’d be happy to share links, etc. with you, but would rather not share everything publicly on the forum. What’s the best way to do that?


(Simon Cossar) #4

Great! I have a developers version of that plugin. It does a few things with login redirects. I’ve enabled it, but so far, everything is working as expected. I’ll keep trying.

Is your forum private? If so, that’s the expected behaviour.

No, if a user who is not logged in visits the forum (http;//forum.example.com), they should be redirected to the WordPress login page and then automatically redirected back to the forum. The ‘Redirect After Discourse Login’ URL is only used when a user logs in directly to the WordPress site, without first visiting the forum. The reason for that setting is that people wanted users to be automatically created and logged in to their Discourse forums after they registered and logged in on WordPress.

Could you try disabling the ‘Create Discourse User on Login’ setting and see if that makes any difference?

What do you have set as the ‘sso url’ in your Discourse settings? Does it look something like this? (Don’t post your ‘sso secret’ on here.)


(Andrew Pautler) #5

The forum is private, so I agree, I do want it to redirect to the WordPress login. Sorry, I wasn’t saying that is incorrect.

What you describe that should be happening is not. I tried to uncheck the option you mentioned, but it did not work. In Discourse, my SSO URL is my WordPress URL, which is correct, right? The forum URL is: community.kresserinstitute.com if you want to see the redirect setup. I can set you up with a test user if you’d like.


(Simon Cossar) #6

I can reproduce what you are describing with the MemberPress option ‘Force WordPress to use the MemberPress login page’ enabled. It’s found under ‘Options/Account.’ If it’s enabled on your site, try disabling it and see if that helps.

The reason MemberPress has that setting is so that users will be directed to the MemberPress login page, instead of the default WordPress one. You can achieve the same result by disabling that setting and adding the path to your MemberPress login page to the ‘Path to your login page’ setting on the wp-discourse SSO/SSO-Provider options tab. (For your site, that option should be set to /login)

You may find that there is an issue with SSO email verification and the MemberPress plugin. If so, it’s something that can be worked out.


(Andrew Pautler) #7

Ah, perfect. Disabling the ‘Force WordPress to use the MemberPress login page’ option did fix the problem. I’ll have to test some more to see if there are any adverse side effects from disabling that option (outside of the direct Discourse integration). For now it seems to be working though. Thank you for your help!


(Andrew Pautler) #8

@Simon_Cossar We noticed another ‘bug’ with this setup. With the changes we made above, the main registration process and login form work correctly to redirect to the WordPress site.

On pages that are protected though, say —————.com/dashboard, MemberPress shows a message to users that the content is only for users and includes a login form. In this instance, the login form redirects the user to Discourse vs. WordPress. My guess is that this form uses the default MemberPress form and so has the same issues we had when the ‘Force WordPress to use the MemberPress login page’ option was checked. Any ideas how to get around the issue? Hypothetically we could hide the login form on protected pages and direct them back to the main login page, but that isn’t ideal.


(Simon Cossar) #9

I’ll have to take a look at it. It should be fairly easy to figure out.


(Andrew Pautler) #10

Thanks @Simon_Cossar, I appreciate it. Let me know what you find out please.


(Andrew Pautler) #11

I was actually able to fix this issue by changing this setting in MemberPress (Screen Shot 2017-06-08 at 2.35.59 PM.png). It redirects everyone to the login page if they don’t have access to a page. This works as at least a temporary workaround. Ideally they would stay on the same page and see the no access message, so if you come up with a solution please share. Thanks!


(Brendan Schlagel) #12

Hi @Simon_Cossar, I have perhaps a similar question…we’re using Woocommerce Memberships and this “WP auto-login to Discourse + redirect back to WP” isn’t working as expected. I thought it might be because I already have some custom redirects set up related to Woocommerce member registration, but actually can’t get it even with those disabled.

I’m currently using:
filter on ‘woocommerce_login_redirect’ - to send people to main dashboard on login
action added with ‘template_redirect’ - to send new members to welcome page immediately after checkout
filter also on ‘woocommerce_registration_redirect’ - to do the same with free (non-purchase) members

However, testing even with all these completely removed from my functions.php, I’m not seeing the expected behavior. When I log in (using the Woocommerce ‘/my-account/’ login url) it doesn’t seem to be redirecting to Discourse and back; if I visit our forum url directly after logged in on WP, I’m not logged in on Discourse.

I think I have all the settings correctly configured including ‘sso allows all return paths = true’…and everything else is working fine with SSO between the sites. If I append ‘/session/sso’ to the Discourse URL it logs me right in. Anything non-obvious I might be overlooking, or possible conflicts you could think of with Woocommerce? I could send you screenshots of my configs if it might help troubleshoot.


(Simon Cossar) #13

I can see a problem in the code that will affect the auto_login process for users that are created through a front-end Woocommerce registration form. I’ll update the plugin tonight or early tomorrow and then see if that fixes your problem.


(Brendan Schlagel) #14

Got it, sounds good - much appreciated!


(Simon Cossar) #15

I haven’t got to this yet. The most likely issue you’re having is that your user’s email addresses haven’t been verified by the plugin. When that’s the case, it won’t automatically login users. You’ll know this is the case if new users on your site are having to confirm their email address with Discourse before they can log into your forum.

This behaviour can be changed with in a site customization.


(Brendan Schlagel) #16

Thanks for the info Simon! Makes sense; looking into this now…surprised to find Woocommerce doesn’t seem to have any built-in way of doing user email verification. Will see what we can do to add that functionality and get this working consistently. Definitely seems like a good idea to make sure we get some kind of verification in place.


(Brendan Schlagel) #17

Quick note to follow up on this @Simon_Cossar — I just installed a plugin that adds email verification for Woocommerce-created WP accounts. And I then added the following filter (I saw you mention in another thread) to our functions.php to disable email verification on the Discourse end:

add_filter( 'discourse_email_verification', 'my_prefix_discourse_email_verification' );
function my_prefix_discourse_email_verification( $require_activation, $user_id ) {
    return false;
} 

However we just tried with a brand new test user, and the login / new user redirects with WP Discourse still do not seem to be working. The linked Discourse account seems to be created and functional (and we’re no longer getting the Discourse verification email), so this is almost all working, just still not seeing redirects for the automatic login. Is there perhaps something else I need to add to make this work?


(Simon Cossar) #18

Yes, that code above doesn’t affect the auto-login function. Try adding something like this as well.

add_filter( 'wpdc_auto_create_login_email_verification', 'my_namespace_auto_login_user' );
function my_namespace_auto_login_user() {
	return true;	
}


(Brendan Schlagel) #19

Ah, thanks Simon! Perfect, got that working now :slight_smile:

Related question — if I want to filter the actual redirect URL as well, in certain cases (e.g. if user = admin, redirect to backend WP dashboard), would I use the ‘wpdc_auto_create_login_redirect’ filter?

I want to do something like:

add_filter('wpdc_auto_create_login_redirect', 'ccmm_wpdc_login_redirect');
function ccmm_wpdc_login_redirect ($redirect, $user_login, $user) {
    if ($user->has_cap('administrator')) {
        $redirect = admin_url();
        return $redirect;
    } else {
    	return $redirect;
    }
}

I think I’m on the track but not quite getting this right, anything obviously wrong w/ how I’m using this? Appreciate your help with this!


(Simon Cossar) #20

@bts you need to pass the priority and accepted_args parameters to the add_filter call so that you can access the $user variable.

Try this:

add_filter('wpdc_auto_create_login_redirect', 'ccmm_wpdc_login_redirect', 10, 3);
function ccmm_wpdc_login_redirect ($redirect, $user_login, $user) {
    if ($user->has_cap('administrator')) {
        $redirect = admin_url();
        return $redirect;
    } else {
    	return $redirect;
    }
}