Avoid using HTTP 500 for unauthenticated requests #148

New Issue

Closed

opened 2025-06-03 21:39:37 +00:00 by ic3w0lf22 · 1 comment

ic3w0lf22 commented

2025-06-03 21:39:37 +00:00

Member

Description:

Currently, the backend is returning HTTP 500 Internal Server Error when a user is not authenticated. This status code should only be used when an actual server-side error occurs (e.g., unhandled exceptions, database failures, etc.).

Expected Behavior:

When a user is not authenticated, the server should return:
- 401 Unauthorized — if authentication credentials are missing or invalid.
- 403 Forbidden — if the user is authenticated but not authorized to access a resource.

Why this matters:

HTTP 500 indicates a bug or failure within the backend itself.
Using it incorrectly:
- Makes debugging harder.
- Misleads frontend developers and monitoring tools.
- Obscures actual errors when they occur.

Acceptance Criteria:

All routes that check for authentication return 401 or 403 appropriately.
500 is only returned for unexpected, unhandled errors in backend logic.

**Description:** Currently, the backend is returning **HTTP 500 Internal Server Error** when a user is not authenticated. This status code should **only be used when an actual server-side error occurs** (e.g., unhandled exceptions, database failures, etc.). **Expected Behavior:** - When a user is **not authenticated**, the server should return: - **401 Unauthorized** — if authentication credentials are missing or invalid. - **403 Forbidden** — if the user is authenticated but not authorized to access a resource. **Why this matters:** - HTTP 500 indicates a bug or failure within the backend itself. - Using it incorrectly: - Makes debugging harder. - Misleads frontend developers and monitoring tools. - Obscures actual errors when they occur. **Acceptance Criteria:** - [ ] All routes that check for authentication return `401` or `403` appropriately. - [ ] `500` is only returned for unexpected, unhandled errors in backend logic.