Previous tokens invalidation on email update

[chnfyi]

Hi,

Successful confirmPasswordReset and confirmEmailChange invalidate the specific record previous tokens as expected, same when updating record with record.setPassword(pass) and $app.save(record) in a hook or a route.

But it should also be the case when a user email is updated by a superuser and when updating record with record.setEmail(email) and $app.save(record).

[ganigeorgiev]

I'm not really sure (especially if there are other identity fields). The confirmEmailChange endpoint is kind of a special case here.

I've added a more generic task in the roadmap to think a little more on it but for now this remains a low priority.

[ganigeorgiev]

I've pushed in the develop branch small change that invalidate old tokens for now only on email field change for consistency with the confirm-email-change endpoint.
For the other identity fields for now it is left as it is to avoid introducing unnecessary breaking changes as the behavior is not clearly defined and may not be expected by users (regular users can change the email only through the confirm-email-change endpoint but this is not the case for the other custom identity fields).

[chnfyi]

Thanks! Just out of curiosity, why did you replace old := e.Record.Original() with a single record retrieval ?

[ganigeorgiev]

Because it is the more "correct" one in this case since e.Record.Original() holds only the state of the record when it was first/initially fetched but users can call app.Save(e.Record) multiple times with different values.

It is essentially a workaround for the current lack of tracking the "last saved" state. Eventually in the future we may start tracking only the changed fields and replace the db call but this will require maintaining an extra concurrent safe map as part of the Record model and I'm still not sure whether it is worth it (I may reconsider it eventually after Go 1.24 and the new more efficient builtin map implementation based on Swiss tables).