Setting new password endpoint

1

Hello,
I have question about allowing updating only part of resource.
There is an endpoint “/accounts” where user can set new password. How to prevent updating other fields than password?
I have decided to create endpoint /accounts/{uuid}/owner-password?securityToken={uuid} and use this endpoint as PATCH with extra securityToken validation.

{
	"data": {
		"type": "owner-password",
		"id": "xxxx",
		"attributes": {
			"password": "NewPassword"
		},
		"relationships": {
			"account": {
				"type" : "accounts",
				"id": "xxxxxx"
			}
		},
	}
}

is it good approach?
Thank you for help.

2

I have a user resource with (among others) two write-only fields: password and passwordResetToken. Both are supplied in PATCH /users/{userId}. They are never returned by the server, only used to pass data from client to server.

If the user is signed in, they can simply patch the password field to change their password.

If the user is not signed in and needs to reset their password (i.e. “forgot password” functionality), they must supply both password and passwordResetToken. They get the token via email, in a process initiated by another endpoint, POST /passwordResets which takes a passwordReset resource that only has a single field, email (which in our case is the username). (This POST operation returns 202 Accepted, so it’s not actually creating/storing a resource, just creating a token, saving it with the user in the DB, and sending the token in an email.)

1 Like
3

Hello Cmeeren
I have also /password-resets endpoint which work in the same way as you described. I have doubts because in my system changing password, changing business email, changing account name are separate business operations. It’s not CRUD where I get data and save to the DB. Despite that those are separate processes they act on the same endpoint /accounts (your users) and I am not able to detect in simply way that, if user provide password and token it’s password change, if only account name then it’s account name change, and if email also then it’s another process of changing business email. Maybe it’s worth to consider making endpoint /password-changes and POST there email, password and security token?

4

Unfortunately that’s impossible for me to answer without knowing a lot more details about what you mean by “separate business operations” and “not CRUD”. I don’t immediately see a problem with the back-end doing one set of operations if the user supplies an email, another set for password + token, and returns an error if both are supplied.

Ultimately you have to do what is feasible for you given your use-case and frameworks, though.

2 Likes