Updating a user's password kills their session

[haydn]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Historically, when the PUT /admin/users/:id route was used to change a user's password (maybe other fields too — I've only tested changing passwords) their current session would not be affected. In the latest version (somewhere after v2.149) their session is immediately killed and they must re-authenticate.

This may have been an intentional change, but it appears to have caused problems for a number of people. I've included a workaround for others hitting this issue.

To Reproduce

I am only able to see this behaviour using the Supabase hosted platform (it's affecting our staging and production apps, but is not present in our development environments). If I connect my local app to the CLI Supabase instance (CLI v1.165 which ships with GoTrue v2.149) then I cannot see this behaviour, if I connect it to a hosted Supabase instance I can see this behaviour.

Here's a simplified version to reproduce with a hosted instance:

1. Create a user with just an email (POST /admin/users).
2. Generate a OTP link for that user (POST /admin/generate_link).
3. Verify user with OTP (POST /verify).
4. Update that user's password (PUT /admin/users/:id).

After step 3 the user has a session, but after step 4 the user no longer has a session.

Expected behaviour

In earlier versions (such as v2.149) the user's session would not be affected by their password being updated.

Screenshots

N/A

System information

This is on the Supabase hosted platform — I'm not sure of the GoTrue version. Is there somewhere I can see the version numbers in the dashboard? 🤷

Additional context

Issues/discussions that are possibly related:

• https://github.com/orgs/supabase/discussions/23715
• https://discord.com/channels/839993398554656828/1235896967754682478/1235896967754682478

Terms people hitting this issue might be searching for:

• updateUserById
• Session from session_id claim in JWT does not exist

Workaround

In my case, to retain the historical behaviour, we can re-authenticate the users immediately after the password is updated by signing them in again with supabase.auth.signInWithPassword() (POST /token?grant_type=password).