Updating a user's password kills their session about gotrue

[silentworks]

I don't think this behavior is correct as I might just want to change my password for the sake of changing it, I don't remember being logged out of other services when I do a password change. Also note this is a breaking change since the original behavior has been changed because before you wouldn't be logged out previously and now you are being logged out.

Additionally this breaks the password reset flow when following the reference docs:

• User hit the password reset form and triggers supabase.auth.resetPasswordForEmail
• Email link is clicked which acts as a magic link so it signs the user in
• User fills in the password update form (remember the user is signed in at this point) then hits submit and is now signed out

The problem with the above is the application developer is now aware that .updateUser will destroy a user's session once they have updated their password as this is not documented nor was it working like this before. So the developer has not put anything in place to redirect the user to the sign in page because they weren't aware of this new behavior.

I think this issue should be reopened until the documentation for this new process has been updated and some sort of announcement should be made about this breaking change.

[hf]

This is 100% expected and correct behavior. If a user's password changes, they must be logged out of all places. The user's password didn't change for no reason. For example, suppose the user learns that someone has access to their password and they take action to change it.

The only way to "kick out" the would-be attacker is to revoke all sessions for the user.

[haydn]

@hf Thanks! Good to know this was an intentional change to the platform.

I've said this before about other issues I've run into — it's really frustrating that changes get applied to the production environment before the CLI is updated (or even has a way to use the latest version). It means in situations like this it's impossible to reproduce the behaviour locally until the CLI happens to get updated to the latest version. I'll open issue over on the CLI repo about it.

[hf]

If previously a public API behaved one way and then that behavior has changed even if for security reasons it's a breaking change.

It's not a breaking change if a bug/security issue was fixed. This behavior should have been expected. If there's a problem with a flow not working as intended -- not super clear if that's the case as the code will not log out the user causing the password change, then there's not much further to discuss.

[hf]

Also note this is a breaking change since the original behavior has been changed because before you wouldn't be logged out previously and now you are being logged out.

It's not a breaking change if the previous behavior was buggy and especially in this case as it pertains to security.

I don't remember being logged out of other services when I do a password change.

It's done like this pretty much everywhere. It's industry best practice also.

then hits submit and is now signed out

Is this really true? The code is to log all other sessions: https://github.com/supabase/auth/blob/master/internal/api/user.go#L185

[silentworks]

It's not a breaking change if the previous behavior was buggy and especially in this case as it pertains to security.

If previously a public API behaved one way and then that behavior has changed even if for security reasons it's a breaking change.

It's done like this pretty much everywhere. It's industry best practice also.

This is talking about forgot password, not update password. These are two different things although Supabase treats both as the same thing.

Is this really true? The code is to log all other sessions: https://github.com/supabase/auth/blob/master/internal/api/user.go#L185

I haven't tested this, but going off what's described by OP and the reply you gave I would assume this is true. I will try and get a test project setup to see if this behavior is as I've described.

[haydn]

It was killing the "current" session for me… but maybe that's because the password update was being done via the admin API using the service role? I'm assuming the user's session would be considered a different session than the admin role?