I installed this plugin and things have gone weird

(David Buzz) #1

Before: I could manually login to the discourse no problem, do adminy things etc, but the cookie that was created by the discourse instance wasn’t being propogated to my other subdomain ( we’ll call them discourse.example.com and other.example.com

After: When I attempt to “login” to discourse, it behaves as if I have been successful, in that the login page goes away, and if I’m a new-user registration, I get a welcome email from discourse… but the Banner at the top of discourse still shows “Sign Up” and “Login” buttons, and the GUI clearly thinks I’m not logged in. The cookie that is created during this process IS now accessible from “other.example.com”, so that’s at least something! .


(Sam Saffron) #2

This is not an officially supported plugin, you are going to need to take it up with the plugin author.

(David Buzz) #3

I’ve looked at hte code and it’s like 5 lines long… but I just don’t know enough ruby to grok why it’s doing it…

(David Buzz) #4

…oh, and I’ve asked Bas ( aka “ntauthority” ) for input too… so maybe they’ll turn up here. ?

(David Buzz) #5

Just following up here… I’ve “fixed” my issue with this plugin by tweaking the plugin slightly… instead of allowing the plugin to modify the properties of the _t cookie, I now instead get it to create a different cookie that I call _X .

The workaround I made was to change current_user_provider.rb file to this:

class ExCurrentUserProvider < Auth::DefaultCurrentUserProvider
TOKEN_COOKIX ||= “_X”.freeze
def log_on_user(user, session, cookies)
cookies.permanent[TOKEN_COOKIX] = { value: user.auth_token, httponly: true, domain: :all }

This causes the standard _t authentication cookie to be left as it originally was, and instead creates a new _X cookie in conjunction with the original one… but the new cookie supports all subdomains, not just the one that the _t cookie was create for.