Drupal SSO generates incorrect user sessions

SSO
1

Hello,
We are using SSO from Drupal and an unintentional behavior here is that all users see our Drupal server as logged in in addition to their current session. This is causing a lot of worry and confusion in our community as they see another device logged in that isn’t them.

Can this feature be disabled, or better yet, can we omit a certain IPs to hide our server from the Recent Used Devices list?

5 Likes
2

Using an external SSO provider doesn’t cause it to be listed in this list.

What you see may be an artifact of something else, like creating API keys for users, etc.

5 Likes
7

I have seen this issue before when a Drupal site is the SSO provider for Discourse. I haven’t seen similar issues with other SSO providers. Is there a Drupal module that you are using for SSO? If so, can you let us know where to find it?

You can hide the “Recently used devices” section with CSS. This might be a good temporary fix for the problem.

.control-group.pref-auth-tokens {
    display: none;
}
8 Likes
8

We are using Discourse Forum Integration contrib module https://www.drupal.org/project/discourse

Thanks for the tip we temporarily hid this using CSS. But it would be nice to know if its configurable to somehow only hide our server from the list to allow users to continue to see their recently used devices.

3 Likes
9

I’d suggest reaching out to the Drupal developer - that module’s last update appears to be in 2015, with the listed Discourse version support of 1.2.0.beta5 (released by us in Jan 2015). While I’m happy to see that it still works, not surprising that there are some minor issues.

4 Likes
10

Worth adding too that the Drupal module linked above is available for Drupal 7 only, which will reach end-of-life in November of 2021. (It’s not tomorrow, but it’s soon enough.)

5 Likes
11

Yes thanks, we’re aware (and not thrilled as our site just recently launched :disappointed_relieved: )

4 Likes
12

I had a quick look at the Drupal Discourse module. It’s not clear to me what is causing the issue, but for some reason the User Agent and Client IP are getting set to the Drupal server’s values instead of the user’s IP and User Agent during SSO login. This may be related to how the drupal_goto method works.

One thing I noticed in the module is that it provides some functionality for displaying Discourse content on Drupal. To do this, it is making API requests to Discourse with API credentials included in the query string. This type of API authentication has been deprecated by Discourse. At some point in the near future, these types of requests will stop working. If you are using the module to display Discourse content on your Drupal site, you may need to look into this some more.

This module was last updated in 2015. There is a Drupal Discourse SSO module that has been updated more recently: https://www.drupal.org/project/discourse_sso. I think it only provides SSO functionality though. It doesn’t seem to have any code that adds Discourse content to a Drupal site.

6 Likes
13

Thanks for the additional info Simon. We are indeed doing exactly that, our blog comments section uses a Discourse topic for users to have their discussion, this topic’s content is then also displayed in the blog article back on Drupal.

Would this be the right place to learn more about the API auth deprecation? Discourse API Documentation

Thanks again!

1 Like
14

Yes, the example POST request that’s given at the start of that topic has the information that you need. To fix the Drupal Discourse module to use header based authentication would only require a small change to its code.

Assuming that your Discourse site is up to date, there is probably a warning about using deprecated authentication methods for API requests on your Discourse admin dashboard.

4 Likes