Refactor Role-Based Access Control Logic

[keiranjprice101]

Technical specifics

What:
We need to investigate and implement a centralized pattern for user authorization to replace the current manual checks within our endpoint bodies. The goal of this investigation is to evaluate the pros/cons of using FastAPI Dependency Injection (DI) versus a custom Decorator pattern, (or any other possible solutions) to handle role verification before requests reach the business logic.

Why:

• Maintainability: The "staff" role check is currently hardcoded across multiple files; a change in role hierarchy or naming currently requires a high-risk global refactor.
• Code Quality: Removing this boilerplate allows our route handlers to focus exclusively on their functional logic.
• Security Consistency: A centralized mechanism ensures that 403 Forbidden responses are handled identically across the API, reducing the risk of logic drift or forgotten checks on new routes.

Who (will benefit):

• Developers: Will gain a more readable codebase and a standardized way to secure new endpoints.
• QA/Security: Easier to audit permissions via function signatures or dependencies rather than scanning internal function logic.
• API Consumers: Will receive consistent error schemas and status codes across all protected routes.

How (are we doing this now):
Currently, we manually invoke get_user_from_token and perform an explicit if check at the start of each protected function:

user = get_user_from_token(credentials.credentials)
if user.role != "staff":
    raise AuthError("User not authorised for this action")

Technical caveats:

• Pattern Evaluation: The investigation should weigh the "FastAPI-native" benefits of Dependency Injection (better OpenAPI/Swagger integration) against the potential "cleaner" syntax of a Decorator, or other solutions.
• Dependency Chain: Any new solution must integrate with our existing get_current_user logic to ensure we aren't performing redundant token decoding or database lookups.
• Async Support: The chosen solution must be compatible with async execution to avoid introducing blocking calls into the event loop.