feat: load config authenticated #1249
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements authenticated configuration loading by fetching the config a second time with an authentication token after the user has been loaded. It also removes deprecated application properties to clean up the codebase.
Key changes:
- Adds authenticated config reload functionality after user authentication
- Removes deprecated app properties (
applicationMenu,isFileEditor,type,quickActions) - Refactors TopBar component from Options API to Composition API and removes legacy application menu handling
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packages/web-runtime/src/index.ts | Adds second config load call with authentication token |
| packages/web-runtime/src/container/bootstrap.ts | Updates announceConfiguration to accept optional token parameter |
| packages/web-runtime/src/layouts/Application.vue | Removes deprecated apps store usage and props passing |
| packages/web-runtime/src/components/Topbar/TopBar.vue | Refactors to Composition API and removes legacy application menu logic |
| packages/web-pkg/src/composables/piniaStores/apps.ts | Removes deprecated applicationMenu property from app registration |
| packages/web-pkg/src/apps/types.ts | Removes deprecated type definitions |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Loads the config authenticated so we are prepared when the server sends a user specific config in the future.
JammingBen
force-pushed
the
refactor/load-config-authenticated
branch
from
a3879f2 to
82f9666
Compare
We can savely remove them since there should be no app running using these.
JammingBen
force-pushed
the
refactor/load-config-authenticated
branch
from
82f9666 to
4370a06
Compare
| }) => { | ||
| const request = await fetch(path, { headers: { 'X-Request-ID': uuidV4() } }) | ||
| const request = await fetch(path, { | ||
| headers: { 'X-Request-ID': uuidV4(), ...(token && { Authorization: `Bearer ${token}` }) } |
There was a problem hiding this comment.
Just thinking, what about public links? Should we authenticate with public link auth as well?
There was a problem hiding this comment.
Hmm do you think it's necessary? Isn't public basically always anonymous and therefore non-user-specific?
There was a problem hiding this comment.
True. I guess we can start without and if there'll be good reasons from someone, then we think about it again.
Loads the config a second time authenticated after the user has been loaded.
The acceptance criteria from the story can not be fulfilled because we need routes to load the auth context, and we need apps for the routes. Hence it's not possible to load the apps after the authenticated config. However, this doesn't seem to be needed because the
extensionsprop of an application is defined as arefand is therefore reactive. That means checks on a user-specific config can still be made.Also removes deprecated app properties.
closes #1050