Users are being logged in as the wrong user

[x9sim9]

Hi We are having a really strange issue with devise for some reason a user is using 1 set of credentials and being randomly logged in as another user. The issue happens intermittently and we have started saving the email address used when logging in and comparing it to the current_user being reported from devise and forcing a logout when this happens.

We don't have a reliable way of recreating the issue, it seems to happen randomly but we have about 20 rollbar error reports so we do have some information, not sure what information to provide

Environment

• Ruby 3.3.5
• Rails 7.1.4.2
• Devise 4.9.4

Current behavior

User is being logged in as the wrong user

Expected behavior

User should be logged in as the correct user

What we have tried

Using database session storage and redis session storage, here is the current config

Rails.application.config.session_store :redis_store, url: "#{ENV.fetch("REDIS_URL", "redis://127.0.0.1:6379/0")}/session", expire_after: 30.days, key: Rails.env.production? ? "_new_app_session" : "new_app_session#{Rails.env}", threadsafe: true, secure: Rails.env.production?, same_site: :lax, httponly: true, domain: :all

[matthewford]

@x9sim9 did you manage to track down the issue

[x9sim9]

No I tried a huge number of things but was unable to find the root cause, the only working solution we have now is to store the email address typed on the login page in a cookie and then compare that to the currently logged in user and force a logout when it occurs.

[matthewford]

@x9sim9 would you mind sharing your gemfile, and describing your setup a bit more?

Did you try disabling multithreading?

[johnfullerton01]

Hi Matthew,

Attached is a copy of our Gemfile. We have not yet tried disabling multithreading. Our current Puma configuration uses a thread pool with both the minimum and maximum threads set to 5.

Regarding our setup:

• We use Devise for authentication with a standard username/password login and Redis-backed sessions. Sessions are scoped to the root domain, expire after 30 days, and are secured with same_site: :lax and secure: true (in production).

• Our configuration includes case-insensitive and whitespace-trimmed email authentication, CSRF token cleanup on login, and session timeout handling.

• Request parameters like domain and URL are also considered in the authentication process when needed. Let me know if there’s anything else I can clarify.

Gemfile.txt

Thanks!

[matthewford]

Thanks, are you overriding the session controller or modifying current user in the code

Sent from my iPhone

On Sun, 26 Jan 2025 at 10:11, John Fullerton @.***> wrote:

Hi Matthew,

Attached is a copy of our gemfile. We use Devise for authentication with a standard username/password login and Redis-backed sessions. Sessions are scoped to the root domain, expire after 30 days, and are secured with same_site: :lax and secure: true (in production).

Our configuration includes case-insensitive and whitespace-trimmed email authentication, CSRF token cleanup on login, and session timeout handling. Request parameters like domain and URL are allowed to influence authentication when needed.

Let me know if there’s anything else I can clarify for you. Thanks.

Gemfile.txt https://github.com/user-attachments/files/18549548/Gemfile.txt

— Reply to this email directly, view it on GitHub https://github.com/heartcombo/devise/issues/5740#issuecomment-2614309979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAABV7NBQCKTHNIOKGH3GT2MSYFNAVCNFSM6AAAAABTQ2K5TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGMYDSOJXHE . You are receiving this because you commented.Message ID: @.***>

-- Bit Zesty Limited is a limited company registered in England and Wales.  Registered number: 06883289. Registered office: 5 Colindeep Lane, London, England, NW9 6BX.

[matthewford]

@johnfullerton01 @x9sim9 I've seen this issue in the past, and it recently reoccurred in one of the older applications we support for one of our clients. Could I ask, in your case, when user 1 visits a URL, they are logged in as user 2 and see the original URL? It's not that they see the URL that user 2 was on.

Thanks for the idea of checking if the user session has changed from the login. We implemented a similar check, and it works here is the implementation if anyone else needs it: https://gist.github.com/matthewford/265b7a20219e61a579e558b743dec046

For us, turning off multithreading reduced the occurrences but did not fix the issue entirely.

Could I also see the lockfile? What versions of the gems are you running?

For the application where it recently happened, after upgrading the dependencies, we haven't seen it for a few weeks (Rails 7.0.8 -> 7.2.2); we also removed distribute_reads and used the functionality built into Rails. We also upgraded from Ruby 3 to 3.3.

This issue is also happening with Clearance, which makes me think this isn't just Devise. The problem is particularly bad with any authentication library, as then the user has access to data they should not.

https://github.com/thoughtbot/clearance/issues/781 / https://github.com/thoughtbot/clearance/pull/869#issue-522467777 They claim to have resolved this, but in our application which is an internal intranet app, we do not use page caching, so the cause is not the same in our use case. But Rails also recently implemented the same change in the built-in auth to only set the session cookie once Rails also changed the built https://github.com/rails/rails/pull/52831.

There are also some issues in Rails https://github.com/rails/rails/issues/37812 with Passenger, we used Puma. They also used Mongo where our app like yours used mysql2. They do however mention action cable, do you have that enabled?

As this also happens in Clearance, I suspect this might be an issue with Rails or at least with a combination of gems. That said, I don't think we should close this issue, as there is enough evidence that this does happen, at least until the cause is found.

The only thing I can see in Rails 7.2 is a connection pool is now fiber-safe https://github.com/rails/rails/pull/44219, although unless you're using fibres, I can't see how that helped.

I found some more historical instances, related to caching and thread leaks https://github.com/rails/rails/issues/476 they had issues with rack-timeout and rack-cache, the initial issue with Rails was assets being sent with session headers then being cached has been fixed since.

[matthewford]

@x9sim9 @johnfullerton01 Is your MySQL instance AWS Aurora? https://www.reddit.com/r/aws/comments/jhi0yi/many_many_mysql_aurora_database_issues_anyone_else/

[matthewford]

Are you using AWS Cloudfront? The new defaults add caching to .js endpoints for 1s, and we're supporting an app that had an endpoint where .js wasn't an asset, but also included the previous request cookie.

[x9sim9]

Hi Mathew, we don't think it's an issue with Aurora as we would see evidence of this with other parts of our system, and we don't use a cdn so it's not a caching related issue.

The fact that we can compare the current logged in user returned from devise against the logged in email address negates caching issues.

We do have error reports of when the devise user does not match the email address used to login so we do have some ability to debug the issue but it can take several days or longer between occurrences so it's a very slow process.

As we don't know much about the inner workings of devise it's difficult to know what data is worth capturing to help debug this issue.

[matthewford]

https://github.com/heartcombo/devise/issues/4951 might be related, if you could share the gemfile.lock to see the versions that might help