Implement views that should utilize authorization #1131

New issue

Open

opened 2026-05-25 09:53:13 +00:00 by a22erigr · 0 comments

a22erigr commented

2026-05-25 09:53:13 +00:00

Collaborator

Description

In issue #993 the endpoints were identified. You shall in this issue implement this.
After reviewing the current frontend views and backend endpoints/services, this is my suggested authorization split.

Views/endpoints that should require login:

Settings.js
This view handles account-related functionality such as changing password, enabling/disabling 2FA, changing email and future account settings. These actions should only be available for authenticated users.
Change password view/endpoint
Password changes are sensitive account operations and should always require the user to already be logged in.
Delete account view/endpoint
Deleting an account is a destructive action and should require authentication and confirmation.
Saved dashboard layout/settings (useGridSave)
Dashboard layouts, saved cards and personalized settings are user-specific data and should only be accessible for the authenticated user who owns them.
Add/remove/reset dashboard cards if saved per user
If dashboard state is stored server-side, users should only be able to modify their own dashboard configuration.
Any future profile/account management views
Future profile pages, email updates, security settings or personalization features should require login.
Any endpoint returning user-specific data
Endpoints returning user settings, dashboard layouts, account data or personalized content should require authorization.

Views/endpoints that should require admin authorization:

/roombooking/createMockup
This endpoint creates mock/test data and should not be available publicly in production environments.
/roombooking/delete/{id}
This endpoint deletes booking data and should require authorization. It should preferably use HTTP DELETE instead of GET.
Future mock/debug/test endpoints
Internal development/testing endpoints should only be accessible by admins or developers.
Future sensor management endpoints
Endpoints that create, update or delete sensors should require admin authorization.
Future user management endpoints
Managing users, roles, permissions or deleting other users should require admin privileges.

Views/endpoints that can stay public:

/auth/login
Must remain public because users need access before authentication.
/auth/SignUp
Must remain public so new users can create accounts.
Weather/SMHI views/endpoints
Public read-only weather data from external APIs.
Temperature views/endpoints
Read-only sensor/statistics data with no user-specific information.
Energy views/endpoints
Public energy statistics and read-only monitoring data.
Parking views/endpoints
Public parking availability information without personal/user-related data.
Room booking read/search endpoints
Read-only booking and room availability information.
MapView
Displays public/static map information.
ScheduleView
Can remain public if it only uses public TimeEdit schedule data.
SudokuView
Public game/API functionality with no user-specific data.
ImageView
Public/static image display functionality.
TextView
Public informational/static text content.
About/Legal/Support/Socials pages
Informational public pages should remain accessible without login.

Additional notes:

Some services already contain commented authorization examples, such as EnergyEndpoints.
/roombooking/delete/{id} should preferably use HTTP DELETE instead of GET because it performs a destructive operation.
Public endpoints should still use validation, secure password handling and preferably rate limiting where relevant.

Originally posted by @b25marem in #993 (comment)

What should be done

Implement authorization on the selected Views/card
It should be possible for a guest to still use the page

## Description In issue #993 the endpoints were identified. You shall in this issue implement this. After reviewing the current frontend views and backend endpoints/services, this is my suggested authorization split. Views/endpoints that should require login: * `Settings.js` This view handles account-related functionality such as changing password, enabling/disabling 2FA, changing email and future account settings. These actions should only be available for authenticated users. * Change password view/endpoint Password changes are sensitive account operations and should always require the user to already be logged in. * Delete account view/endpoint Deleting an account is a destructive action and should require authentication and confirmation. * Saved dashboard layout/settings (`useGridSave`) Dashboard layouts, saved cards and personalized settings are user-specific data and should only be accessible for the authenticated user who owns them. * Add/remove/reset dashboard cards if saved per user If dashboard state is stored server-side, users should only be able to modify their own dashboard configuration. * Any future profile/account management views Future profile pages, email updates, security settings or personalization features should require login. * Any endpoint returning user-specific data Endpoints returning user settings, dashboard layouts, account data or personalized content should require authorization. Views/endpoints that should require admin authorization: * `/roombooking/createMockup` This endpoint creates mock/test data and should not be available publicly in production environments. * `/roombooking/delete/{id}` This endpoint deletes booking data and should require authorization. It should preferably use HTTP DELETE instead of GET. * Future mock/debug/test endpoints Internal development/testing endpoints should only be accessible by admins or developers. * Future sensor management endpoints Endpoints that create, update or delete sensors should require admin authorization. * Future user management endpoints Managing users, roles, permissions or deleting other users should require admin privileges. Views/endpoints that can stay public: * `/auth/login` Must remain public because users need access before authentication. * `/auth/SignUp` Must remain public so new users can create accounts. * Weather/SMHI views/endpoints Public read-only weather data from external APIs. * Temperature views/endpoints Read-only sensor/statistics data with no user-specific information. * Energy views/endpoints Public energy statistics and read-only monitoring data. * Parking views/endpoints Public parking availability information without personal/user-related data. * Room booking read/search endpoints Read-only booking and room availability information. * `MapView` Displays public/static map information. * `ScheduleView` Can remain public if it only uses public TimeEdit schedule data. * `SudokuView` Public game/API functionality with no user-specific data. * `ImageView` Public/static image display functionality. * `TextView` Public informational/static text content. * About/Legal/Support/Socials pages Informational public pages should remain accessible without login. Additional notes: * Some services already contain commented authorization examples, such as `EnergyEndpoints`. * `/roombooking/delete/{id}` should preferably use HTTP DELETE instead of GET because it performs a destructive operation. * Public endpoints should still use validation, secure password handling and preferably rate limiting where relevant. _Originally posted by @b25marem in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/993#issuecomment-11585_ ## What should be done + [ ] Implement authorization on the selected Views/card + [ ] It should be possible for a guest to still use the page