Vishesh 'ironeagle' Bangotra 8f398c35df
All checks were successful
continuous-integration/drone/tag Build is passing
Auth / Author Flow Hardening and Client Separation (#1)
# 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>
2025-12-13 13:15:20 +00:00
2025-10-27 17:25:02 +05:30
2025-11-07 21:32:31 +05:30
2025-10-27 17:25:02 +05:30
2025-10-27 17:49:38 +05:30
2025-10-27 17:25:02 +05:30

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:

Edit on CodeSandbox

Edit on StackBlitz

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
No description provided
Readme 1.8 MiB
Languages
TypeScript 98.4%
JavaScript 0.6%
Dockerfile 0.5%
HTML 0.5%