Identify what Views/endpoints should utilize authorization #993

New issue

Open

opened 2026-05-18 11:43:15 +00:00 by a22erigr · 2 comments

a22erigr commented

2026-05-18 11:43:15 +00:00

Collaborator

Description

In pr #973 JWT was implemented. This makes it possible to require users to login before getting access to services. But what should be protected? In my opinion changing password should probably require the user to be logged in.

What should be done

You should give a list of what should require a login to view/do

## Description In pr #973 JWT was implemented. This makes it possible to require users to login before getting access to services. But what should be protected? In my opinion changing password should probably require the user to be logged in. ## What should be done + [ ] You should give a list of what should require a login to view/do

a22erigr added the

frontEnd

unassigned

labels

2026-05-18 11:43:15 +00:00

b25marem was assigned by a22erigr

2026-05-18 16:22:08 +00:00

b25marem commented

2026-05-19 08:35:33 +00:00

Collaborator

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.

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.

b25marem added the

needs review

label

2026-05-19 08:37:09 +00:00