Skip to main content

v0.7.2

nauth-toolkit team

client.admin.setPassword() could not succeed​

The frontend SDK posted the target user as identifier; the route has always expected sub. Unknown fields are stripped before validation runs, so every call came back as a 400 complaining about sub — a field the caller never sent.

Only @nauth-toolkit/client was affected. The route, the DTO and AdminAuthService.setPassword() were correct throughout, so direct HTTP and server-side calls worked all along.

// Temporary password, all sessions revoked — both are the default
await client.admin.setPassword('a21b654c-2746-4168-acee-c175083a65cd', 'NewSecurePass123!');

// Permanent password, sessions left alone
await client.admin.setPassword('a21b654c-2746-4168-acee-c175083a65cd', 'NewSecurePass123!', {
  mustChangePassword: false,
  revokeSessions: false,
});

The first argument is now the user's sub, not an email or username — @IsUUID('4') on the DTO is what the route enforces. Because the options default to true server-side, the plain two-argument call already issues a temporary password and signs the user out everywhere; the follow-up forcePasswordChange() that this bug used to require is no longer needed.

Three admin return types corrected​

Same root cause, one step milder: the SDK declared response shapes the server does not send. These typecheck on both sides independently, so nothing caught them.

MethodWasNow
admin.setMfaExemption(){ message }{ mfaExempt, mfaExemptReason, mfaExemptGrantedAt }
admin.getUser(), admin.getUserByEmail()AuthUserAuthUser | null
admin.revokeUserSession(){ success }{ success, wasCurrentSession }

setMfaExemption() is the one to check your code against — anything reading .message has been getting undefined. The other two only widen what you can rely on: both lookups answer null for a miss rather than throwing.

Every other admin method was audited against the route it calls and needed no change. See Admin operations.