Loading published curriculum…

16 · Spring Security in depth / LESSON 78 OF 102

Registration, validation, and privilege assignment

Registration accepts identity data but must never accept the caller’s desired privileges as authority.

Before this lesson: UserDetailsService and persistent user accounts

Understand the topic

Validate input, normalize the login under an explicit policy, encode the password, and persist in a transaction. A database unique constraint resolves concurrent duplicate registrations. Map duplicate identifiers to a consistent response without leaking internal SQL.

Assign the initial role on the server. Verification and password-reset links need high-entropy random tokens, expiry, one-time consumption, and protected storage such as a hash. Reset responses should not reveal whether the address exists.

EXAMPLE · JAVA

Registration service sketch

// Transactional service with an injected PasswordEncoder and account repository.
String normalized = request.email().strip().toLowerCase(java.util.Locale.ROOT);
String hash = passwordEncoder.encode(request.password());
// The repository insert must rely on a UNIQUE normalized-email constraint.
accountRepository.create(normalized, hash, "ROLE_USER");

What to expect

This illustrates the trusted boundary; implement request validation, the repository insert, and conflict handling. ROLE_USER is server-assigned even if the request contains a role field.

YOUR TURN

Put it into practice

  1. 01Build registration with a unique normalized login and server-owned role.
  2. 02Race two identical registrations and attempt to submit an admin role in the payload.
  3. 03Verify: Exactly one account is created, its role stays USER, and duplicate handling is deterministic.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Registration accepts identity data but must never accept the caller’s desired privileges as authority.

  1. 01Validate input, normalize the login under an explicit policy, encode the password, and persist in a transaction. A database unique constraint resolves concurrent duplicate registrations. Map duplicate identifiers to a consistent response without leaking internal SQL.
  2. 02Assign the initial role on the server. Verification and password-reset links need high-entropy random tokens, expiry, one-time consumption, and protected storage such as a hash. Reset responses should not reveal whether the address exists.
  3. 03Trace the example: This illustrates the trusted boundary; implement request validation, the repository insert, and conflict handling. ROLE_USER is server-assigned even if the request contains a role field.

A mistake worth avoiding

A newly registered caller becomes an administrator.

DEBUGGING ROOM

Something broke. Where do you look?

A newly registered caller becomes an administrator.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Should a registration payload decide the new account’s role?

Choose one answer

BUILD IT YOURSELF

Build registration with a unique normalized login and server-owned role.

  1. 1.Build registration with a unique normalized login and server-owned role.
  2. 2.Race two identical registrations and attempt to submit an admin role in the payload.
  3. 3.Reproduce this failure, then repair it: A newly registered caller becomes an administrator.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Should a registration payload decide the new account’s role?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

Exactly one account is created, its role stays USER, and duplicate handling is deterministic.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references