We have SSO enabled for our Discourse instance. When logged in to our product, but we keep getting reports from customers and staff like this one:
Any other SSO users out there see anything like this?
Thanks!
Can you repro this @jomaxro?
1 Like
Hey there @hross, I’ll be looking into this tomorrow. Can you PM me some credentials so I can test login?
Edit: Scratch that, just saw that accounts are free…
Yes I can repro this.
Steps taken:
- Registered for a New Relic account.
- Navigated to
https://discuss.newrelic.com - Clicked Sign In
- Clicked Sign In (in modal that appeared)
- Redirected to
https://login.newrelic.com/login?...in same window. - Entered New Relic credentials and clicked Sign In
- Redirected back to
https://discuss.newrelic.com - Saw Register User modal appear for <1 sec.
- Forums appeared to refresh, still not logged in.
Note, I tested this in Google Chrome (60) and Internet Explorer (11) on Windows.
1 Like
Were you actually logged in if you refreshed the browser, though?
No. Refreshing the page manually did not cause me to be logged in.
OK - so we’re not crazy. The problem exists! What can we do to help solve the problem?
Hey folks - maybe some more clues.
We have customers who have multiple accounts on our product, with different login credentials. But they often have just one community account. I just ran into this issue myself after being logged into our NR product with an alternate set of credentials. When I came back to discuss, got that weird loopy thing after clicking the login button. I think discuss did not know which set of credentials to use?
As soon as I cleared my cache and cookies from the last hour, I was able to use the login button normally.
@mmayo ^ I know you are looking at this from our side as well.
Hey @jomaxro and @codinghorror - what else can we be doing to help diagnose this?
Apologies, looks like we lost track of this one. Most of the team is currently on a week long company retreat to India – the only time we see each other in person all year, as we are a fully remote company – so resolving this could take a bit longer than normal.
@gerhard, can you take a look at this tomorrow?
2 Likes
Thanks so much @jomaxro - India! So jealous! Totally patient over here as long as it’s still on the list to be looked at.
I have been poking at this this morning, and I believe I’ve tracked this down to the following line:
Looks like this is a bit of housekeeping after the page renders - any thoughts on how to work around this call to closeModal ?
FYI @hross
1 Like
Me too! They left me behind 
…
…truthfully I joined the team too close to the trip to join them. As you may be able to imagine, organizing the logistics of a trip like this - everyone starting in a different country, visas, planes, buses, lodging, etc. - is quite complicated. Planning starts months in advance. I joined the team after most of the planning was complete. With that in mind, I’m already thinking about 2018!
3 Likes
I’ve got a clearer picture of the order of events here:
After the user redirects from our site, we do the following:
ApplicationRoute.on('activate', function() {
... get users auth info and build options hash
}).then(function(options) {
Em.schedule('afterRender', function() {
Discourse.authenticationComplete(options)
})
})
cleanDOM is called before authenticationComplete in page-tracking.js, but the scheduled call to .send('closeModal') isn’t executed until after the modal is rendered, and ends up getting squashed. I’ve been researching Ember’s run loop to see if there is better way to work out the scheduling, but haven’t found a solution yet. If y’all have any suggestions, they’re certainly welcome.
1 Like
Thanks for researching this so thoroughly. I’ve come to the same conclusion, but I have no solution right now. We will get back to you as soon as everyone is back from India. I hope that’s alright with you.
I’ve set myself a reminder for Monday, so that we don’t lose track of this one more time.
5 Likes
Thanks! It’s not urgent in the sense that it’s mostly fine BUT, this has significantly negatively impacted our new sign ups:
Hi Micah,
I took a quick look at what you’re doing and I think I have an idea of the problem.
You are using ApplicationRoute.on('activate') to trigger your logic. This will start when you enter the route. Sometimes the AJAX request happens quite fast and schedules the authenticationComplete to appear before all nested routes have been entered. Then, when a nested route finishes transitioning the page-tracking module is triggering a cleanDOM which removes the modal.
I can think of a few things to try:
-
Instead of watching
ApplicationRoute.on('activate')you could instead trigger it from theDiscoveryCategoriesRoute- that is a nested route in your homepage that should fire after theApplicationRoutedoes -
You might have more luck with the didTransition action than
on('activate'). -
Finally, if neither of those work, you could try adding your logic to the
didInsertElementof thediscovery-categoriescomponent. That will only fire after that component has been rendered, which should be well after any transition has happened.
5 Likes
Thanks for this advice. I ended up attaching our logic to the DiscoveryCategoriesRoute, via the didTransition action. This appears to be working well, at least locally. I’ll be testing in staging soon and will update this topic if we encounter any other issues.
I do want to point out for anyone who might be struggling with a similar timing issue: DiscoveryCategoriesRoute only works because our default landing page is the categories page. If we changed it to Topics, New or anything other than Categories, the modal wouldn’t be scheduled to run unless the user navigated to the Categories page-- which might be a bit confusing. 
I’d imagine the same kind of thing could be done for some other route or component in that case.
At any rate, this will work in our use case, and thanks again for the help.
4 Likes