Xpensely Server is a Spring Boot REST API that manages shared expense lists for pairs of users. It uses Google OAuth2 JWT tokens for authentication. All protected endpoints require a valid Bearer token in the `Authorization` header.
**Base URL (local dev):**`http://localhost:8080`
**Content-Type:**`application/json` for all request and response bodies.
**Public endpoints (no auth required):**
| Method | Path | Description |
|--------|------|-------------|
| GET | `/` | Health check — returns `"Welcome"` |
| POST | `/api/users/createUser` | Register a new user |
| GET | `/api/users/byName` | Look up a user by username |
All other endpoints require authentication (see [Section 2](#2-authentication)).
The server uses **OAuth2 Resource Server** authentication with **Google ID JWT tokens**.
### How it works
1. The client authenticates with Google and receives a Google ID JWT.
2. Every protected API request must include this token in the header:
```
Authorization: Bearer <google-id-jwt>
```
3. The server validates the JWT signature and extracts the `sub` claim (Google User ID).
4. The `sub` value is used to look up the registered `AppUser` in the database via `AuthenticatedUserResolver`.
5. If no `AppUser` exists for that Google ID, the request is rejected with **403 Forbidden**.
### Test profile
When the application runs under the `test` Spring profile (`-Dspring.profiles.active=test`), **all security is disabled** — every endpoint is accessible without a token. This is used for automated tests only.
### User registration flow
Before a user can call any protected endpoint they must first be registered:
1. Authenticate with Google to obtain a Google ID JWT.
2. Call `POST /api/users/createUser` with the JWT's `sub` value as `googleId` and a chosen `username`.
3. All subsequent protected calls use the same JWT — the server resolves the caller automatically.
All errors are returned as JSON. The `GlobalExceptionHandler` (`@RestControllerAdvice`) maps exceptions to HTTP status codes consistently across every endpoint.
### Error response format
Most errors:
```json
{
"error":"Human-readable message"
}
```
Validation errors (`400`):
```json
{
"username":"size must be between 3 and 30",
"googleId":"must not be blank"
}
```
### Status code reference
| HTTP Status | Condition | Source |
|-------------|-----------|--------|
| 400 Bad Request | Input validation failed (missing/invalid fields) | `MethodArgumentNotValidException` via `@Valid` |
| 400 Bad Request | Business rule violation (e.g. expense not in this list) | `IllegalArgumentException` |
| 403 Forbidden | User not registered in the system | `AuthenticatedUserResolver` → `ResponseStatusException(FORBIDDEN)` |
This section summarises API-visible changes introduced on the `feature/security-hardening` branch (commits `3d456f2` → `b1324e3` → `8b96433` → `f0de751`). A developer or agent reading this document should be aware of these differences compared to the `main` branch.
All error responses now follow the consistent JSON shape described in [Section 6](#6-error-handling). Previously, individual controllers returned ad-hoc responses, including HTTP 417 and raw stack trace output. Both have been removed. SLF4J logging has been added for server-side error visibility.
A new component that extracts the Google ID from the JWT `sub` claim and resolves the corresponding `AppUser`. Injected into all protected controller methods. Returns `403 Forbidden` if the token is valid but the user has never called `POST /api/users/createUser`.
`POST /api/expenselist/create` previously accepted a raw `ExpenseList` body. It now requires a `CreateExpenseListRequest` with a single validated `name` field (`@NotBlank`, `@Size(max=100)`). Clients must update their request body shape.
---
### Updated: Validation constraints tightened on existing DTOs
| DTO | Field | Change |
|-----|-------|--------|
| `AppUserCreateRequest` | `username` | Added `@Pattern(regexp="^[a-zA-Z0-9_.\-]+$")` — special characters (other than `_`, `.`, `-`) now rejected |
| `InviteRequest` | `inviteCode` | Added `@Size(min=6, max=6)` — non-6-char codes now rejected at binding |
| `ExpenseInput` | `amount` | Added `@DecimalMin("0.01")` — zero and negative amounts now rejected |
| `ExpenseChangeRequest` | `amount` | Added `@DecimalMin("0.01")` — zero and negative amounts now rejected |
-`@Profile("!test")` — full JWT/OAuth2 enforcement (production behaviour).
Previously a single config was used for both, which made tests fragile.
---
### Fixed: `ExpenseListService` — JPQL and exception consistency
- Single `@Param` used in all JPQL queries (multi-param variant was broken).
-`ResourceNotFoundException` is now thrown consistently instead of returning `null` or a generic `RuntimeException`.
-`addExpenseToList` delegates directly to `ExpenseList.addExpense()` rather than looping.
---
### Fixed: `UserService` — null returns replaced with exceptions
All not-found paths in `UserService` now throw `ResourceNotFoundException` instead of returning `null`. Callers that previously needed to null-check responses will now receive a `404` response.