0.3.0
All checks were successful
continuous-integration/drone/tag Build is passing
# Merge Request: Auth / Author Flow Hardening and Client Separation ## Summary This change set improves the authentication–author lifecycle by clearly separating **Auth** and **Blog API** clients, ensuring an **Author is created at registration time**, and preventing user-controlled mutation of immutable identity fields in the UI. The result is a cleaner contract between services, fewer edge cases around missing authors, and more predictable client behavior. --- ## Key Changes ### 1. Username Made Read-Only in Profile UI - Disabled the `username` field in `Profile.tsx` - Prevents accidental or malicious mutation of identity-bound fields - Aligns UI behavior with backend ownership rules --- ### 2. Dedicated Auth vs Blog API Clients - Introduced a separate Axios client for the Auth service (`auth`) - Blog service continues to use `api` - Both clients: - Automatically attach JWT tokens - Share centralized `401` handling and token invalidation logic **Why:** Auth and Blog are separate concerns and potentially separate services. Explicit clients reduce coupling and eliminate ambiguous routing. --- ### 3. Registration Flow Now Creates Author Automatically - `register()` now: 1. Registers the user via Auth service 2. Creates a corresponding Author via Blog API This guarantees: - Every authenticated user has an Author record - No race condition or implicit author creation later --- ### 4. Correct Endpoint Usage for “Current User” - `/auth/me` is now correctly called via the Auth client - `/authors/me` replaces ID-based lookup for the current author - Eliminates dependency on user ID leaking across service boundaries --- ### 5. Centralized Token & Auth Error Handling - Shared request interceptor to attach JWT tokens - Shared response interceptor to handle `401` consistently - Token invalidation is now uniform across services --- ### 6. Environment Configuration Updated - Added `VITE_AUTH_BASE_URL` to support separate Auth service routing - Explicit environment contract avoids accidental misconfiguration --- ## Impact - Cleaner service boundaries - Deterministic user → author lifecycle - Reduced client-side complexity and edge cases - More secure handling of identity fields --- ## Notes / Follow-ups - Optional auto-login after registration is scaffolded but commented - Logout or redirect handling on `401` can be wired later via an event bus or global handler --- **Risk Level:** Low **Behavioral Change:** Yes (author auto-created on registration) **Backward Compatibility:** Requires Auth + Blog services to be reachable separately Reviewed-on: #1 Co-authored-by: Vishesh 'ironeagle' Bangotra <aetoskia@gmail.com> Co-committed-by: Vishesh 'ironeagle' Bangotra <aetoskia@gmail.com>
Material UI - React Router example in TypeScript
How to use
Download the example or clone the repo:
curl https://codeload.github.com/mui/material-ui/tar.gz/master | tar -xz --strip=2 material-ui-master/examples/material-ui-react-router-ts
cd material-ui-react-router-ts
Install it and run:
npm install
npm run dev
or:
The idea behind the example
This example demonstrates how you can use Material UI with React Router in TypeScript.
It includes @mui/material and its peer dependencies, including Emotion, the default style engine in Material UI.
What's next?
You now have a working example project. You can head back to the documentation and continue by browsing the templates section.
Description
Languages
TypeScript
98.4%
JavaScript
0.6%
Dockerfile
0.5%
HTML
0.5%