WordPress SSO Page Template

(raul) #13

@ Adam, fantastic! I commented out line 43 and 47 and it worked! Thanks a ton!

if ( isset( $_GET[‘fresh’] ) && $_GET[‘fresh’] == true ) {

According to the comment this line is sanitizing the redirect URL, so it seems it creates an issue on my end.

I tested this in both scenarios;

  1. Logged out of both Wordpress and Discourse and then logging into Discourse. Success.

  2. Already logged in to Wordpress only and then trying to log in into Discourse. Success. This was failing earlier.

So now it works for both.

(Adam Capriola) #14

Great! It seems like the issue is that the character %0A was lost from the payload for some reason. WordPress will strip the character out of from redirect URLs, so I had to add it back in on a “fresh” WordPress login. I’m not sure why it would be lost otherwise (it wasn’t for me); I guess I’ll need to add a catch-all check to look for it at the end of the string and if it isn’t there then add it.

(Adam Capriola) #15

I’ve made a slight update to the page template which should now better account for the %0A needed at the end of the payload. I also added an error message if @ArmedGuy’s helper class is not properly included.

(Matt) #16

I’m a bit stuck trying to implement this.
I’ve configured the wordpress page template but I’m not sure what to put for the discourse_url.

I’m also not sure how to include ArmedGuys’ help class.

I’m struggling with this and be so appreciative of any help you could offer.

Thank you!

(Adam Capriola) #17

discourse_url is where your Discourse install resides.

The easiest way to include the helper class would be to copy it and tack it onto your theme’s functions.php file. You might even be able to add it onto the page template but I’m not 100% sure that will work. (You could try though.)

(Steven Greco) #18

This is what I had done. I just added an include statement into the template file itself for the helper class. It works great. thanks for the work on this.

SSO from Wordpress for Two Different Discourse Sites
(Matt) #19

It works!
Thank you.

Do you know how I might set this up for Wordpress multisite? Does it work with WPMU?

(Adam Capriola) #20

I’m not sure; I’m not real familiar with how WPMU works. Are plugins applied across all users/sites? A plugin version of this instead of a page template might do the trick.

(Matt) #21

It seems to work ok with WPMU as is actually! Regardless of which subset I log in from it logs in to Discourse fine! I’m super happy!

Thank you again!

(Steven Greco) #22

Question. Within the Discourse setting there are some SSO overrides. Currently i have these turned off. @AdamCapriola are you passing this information over in the playload? I would like to keep the user experience and close as I can from a user going from WP to Discourse. How do these affect the profile on Discourse?


(Adam Capriola) #23

You definitely want to override username. I also override name but I have users manage their display name in WordPress and I then sync it to Discourse from there. I do the same for email, but instead of checking to override email I use CSS to hide to email changing field on the user profile page. (It’s not a perfect solution, but I needed to work around this.)

.user-preferences .pref-email {
    display: none !important;

I send Discourse avatars over to WordPress so I leave that unchecked.

(Steven Greco) #24

awesome. thanks for the info.

(Steven Greco) #25

Can we pass custom field info over with the payload data? I have a few custom fields on my Wordpress site and i created matching custom fields on the Discourse side as well. Is there a way i can pass that data over.


(Adam Capriola) #26

@Grex315 You should be able to add them in the $params array I think.

I’ve made a somewhat important update to the page template today. If you are on Discourse version 1.2.0.beta3 you’ll need to be using the new version of the template otherwise you will probably have login troubles.

%0A gets stripped from the payload by WordPress in certain login scenarios. Before this version of Discourse I think there was only one instance of %0A in the payload on the very end, so I simply did a check to tack it on if it was missing.

With the current version of Discourse, there are multiple %0A in the payload, so instead what I’ve done is converted all of them to %0B and then back to %0A right before the payload is to be validated. I think this is a safe solution. If anyone has any other ideas, please share! (Maybe converting it to something other than %0B is better – it needs to be a unique dummy string.)

(Matt) #27

I’ve updated to the latest version of the page template but I’m getting the invalid request error.

As you say the older version of the page template is not working with 1.2.0.beta3.

Please let me know what I could try.
Thank you!

(Sam Saffron) #28

You need to follow the protocol, none of this 0a and 0b shaningens.

Payload is base 64 encoded

And then url encoded

(Matt) #29

Hi @AdamCapriola are there any edits I can make based on what @sam has posted? Or, is this something than needs to be changed in the page template?
I’m trying to get this sorted out as soon as possible as my users require SSO through our wordpress site.

Thank you!

(Adam Capriola) #30

@matt5834 Did you remember to update the variables at the top of the template?

@sam I think the helper class is handling that? https://github.com/ArmedGuy/discourse_sso_php/blob/master/discourse_sso.php

(Matt) #31

I did update the variables the sso_secret
and the sso_url

Are there any changes I need to make to the helper class?

Also, there seems to be a new option in Discourse: "Implement Discourse SSO protocol at the /session/sso_provider endpoint, requires sso_secret to be set"
Should that be checked?

(Kane York) #32

Nope. That’s for if you want one Discourse to be authenticating a different one.