Menghubungkan Pendaftaran dan Login

You've picked a provider. Now you wire it in. The goal of this lesson is a working sign-up form, a login form, and a session that persists across page loads.

Build it in small, testable steps. Prompting for the whole flow at once often produces tangled code you can't debug. One piece at a time keeps you in control.

First, install the provider's SDK and initialize a client with your keys. The public key goes in client config; the secret stays server-side in environment variables.

Get this base layer working before any UI. A quick test — calling the client and printing the current (empty) user — confirms the connection is alive.

Sign-up needs an email field, a password field, and a submit handler that calls the provider's createUser method. Keep the form minimal at first.

On success, the provider returns a new user record. On failure — like a duplicate email — it returns an error you must show to the user. Don't swallow errors silently.

Catch bad input before it reaches the provider. Check that the email looks valid and the password meets a minimum length. This gives instant feedback and reduces useless API calls.

Remember client validation is for UX only — never security. The provider and server must validate again, because anyone can bypass the browser.

Many providers send a verification email after sign-up. Until the user clicks the link, their account is unconfirmed and may have limited access.

Decide your policy: block login until verified, or allow it with a banner reminder. Tell your assistant explicitly, since the default behavior varies by provider.

Login mirrors sign-up: email, password, and a handler that calls signIn. On success the provider issues a session and stores it; on failure you show "invalid credentials."

Keep the error message vague on purpose. Telling an attacker whether the email exists helps them. A single generic message is the safer default.

After login, the session must survive page refreshes and new tabs. Providers usually handle this with a cookie or local storage, but you need to load it on app startup.

Add logic that checks for an existing session when the app mounts, so a returning user isn't asked to log in again unnecessarily.

Once a session loads, your UI needs to know who's logged in. A small piece of shared state — often a context or store — holds the current user and updates the whole app.

With this in place, components can react: show a profile menu when logged in, or a login button when not. It's the backbone of a logged-in experience.

A logout button calls the provider's signOut method, which clears the session and cookie. Your shared user state should then reset to null, flipping the UI back to the logged-out view.

Test it properly: after logout, refreshing should keep you out and any protected page should reject you. A button that only hides the UI is a bug.

Real auth fails in predictable ways: wrong password, unverified email, network timeout, duplicate sign-up. Each deserves a clear, friendly message.

Ask your assistant to map common provider error codes to user-facing text. Good error handling is what separates a demo from a product people trust.

Before moving on, run the full loop yourself: sign up a new account, verify the email, log out, log back in, refresh, and log out again.

Watching it end to end catches gaps that unit tests miss — like a session that doesn't persist or a logout that leaves a stale cookie. Trust the flow only after you've walked it.

You wired auth in small steps: configure the client, build sign-up with validation and email confirmation, build login with safe error messages, then persist the session and expose the current user.

You added logout, mapped errors to friendly text, and tested the full loop by hand. Next you'll lock down the pages and data only logged-in users should reach.