Maybe this is more of a usage question - but it seems like if a user changes their username their password will be invalidated as a side-effect. The documentation may want to adjust its suggested workflow to one which will allow users to modify their username / email without getting locked out of their account.
I'm not 100% sure of the right approach. I guess when the client sends the first request to the server, it can provide some token back to the client which identifies the user. If this has to be anonymous, the token would seemingly have to be something randomly generated (e.g. not a database user ID). This is kind of redundant with the salt, though, which in principle you could just require each account to have a unique salt and use the salt to find the user in a subsequent request.
Maybe this is more of a usage question - but it seems like if a user changes their
usernametheir password will be invalidated as a side-effect. The documentation may want to adjust its suggested workflow to one which will allow users to modify their username / email without getting locked out of their account.I'm not 100% sure of the right approach. I guess when the client sends the first request to the server, it can provide some token back to the client which identifies the user. If this has to be anonymous, the token would seemingly have to be something randomly generated (e.g. not a database user ID). This is kind of redundant with the salt, though, which in principle you could just require each account to have a unique salt and use the salt to find the user in a subsequent request.