kodi
152 lines
6.2 KiB
Markdown
152 lines
6.2 KiB
Markdown
# UI_VOLUMES_DIRECTORY_VIEW_V1
|
|
|
|
## 1. Doel
|
|
|
|
Doel van deze stap is om de webui een host-achtige navigatiestructuur te geven waarbij de gebruiker eerst `/Volumes` ziet en daarna daarbinnen de beschikbare mounts kan openen, zoals:
|
|
|
|
- `/Volumes/8TB`
|
|
- `/Volumes/8TB_RAID1`
|
|
|
|
Waarom dit gewenst is:
|
|
- het sluit beter aan op de werkelijke host- en containerstructuur
|
|
- het voorkomt dat technische aliasnamen zoals `storage1` en `storage2` het primaire navigatiemodel bepalen
|
|
- het maakt de UI begrijpelijker voor gebruikers die denken in echte mountpunten en directories, niet in app-specifieke labels
|
|
|
|
---
|
|
|
|
## 2. Gewenste UI-weergave
|
|
|
|
Gewenst gedrag in beide panelen:
|
|
- een paneel kan op `/Volumes` staan als huidige directoryweergave
|
|
- in die weergave ziet de gebruiker de toegestane submappen als normale directory entries
|
|
- voor deze case moeten daar minimaal zichtbaar zijn:
|
|
- `8TB`
|
|
- `8TB_RAID1`
|
|
|
|
Navigatieflow:
|
|
- gebruiker opent of kiest `/Volumes`
|
|
- de lijst toont `8TB` en `8TB_RAID1` als directories
|
|
- klikken of `Enter` op `8TB` opent `/Volumes/8TB`
|
|
- klikken of `Enter` op `8TB_RAID1` opent `/Volumes/8TB_RAID1`
|
|
|
|
Voor dual-pane gedrag:
|
|
- beide panelen moeten onafhankelijk op `/Volumes` of op een onderliggende mount kunnen staan
|
|
- er is geen speciaal verschillend gedrag nodig tussen links en rechts
|
|
- breadcrumbs moeten `/Volumes` en daarna de mountnaam tonen
|
|
|
|
---
|
|
|
|
## 3. Relatie met huidige whitelist/root-configuratie
|
|
|
|
Huidige situatie:
|
|
- de backend werkt met expliciete toegestane roots via aliases
|
|
- defaults zijn nu:
|
|
- `storage1 -> /Volumes/8TB`
|
|
- `storage2 -> /Volumes/8TB_RAID1`
|
|
|
|
Belangrijk verschil:
|
|
- de huidige whitelist geeft alleen directe toegang tot specifieke roots
|
|
- `/Volumes` zelf is op dit moment conceptueel geen browsebare root in het bestaande model
|
|
|
|
Voor het gewenste gedrag is een extra browsebaar niveau nodig:
|
|
- niet als volledig vrije root over het hele filesystem
|
|
- maar als gecontroleerde containerdirectory die alleen als bovenliggende presentatie-laag dient voor de whitelisted mounts
|
|
|
|
Cruciale eis:
|
|
- als `/Volumes` zichtbaar wordt, mag niet automatisch alle andere inhoud van `/Volumes` browsebaar worden
|
|
- alleen de expliciet toegestane mounts onder `/Volumes` mogen zichtbaar zijn
|
|
|
|
---
|
|
|
|
## 4. Veiligheidsmodel
|
|
|
|
Aanbevolen veiligheidsmodel:
|
|
- `/Volumes` wordt niet behandeld als een normale vrije root
|
|
- `/Volumes` wordt behandeld als een virtuele of gecontroleerde container-directoryweergave boven de bestaande whitelisted roots
|
|
|
|
Veilige semantiek:
|
|
- de UI/backend toont in `/Volumes` alleen de mountnamen die corresponderen met toegestane roots
|
|
- voor deze case dus alleen:
|
|
- `8TB`
|
|
- `8TB_RAID1`
|
|
- andere directories onder de echte `/Volumes` mogen niet automatisch zichtbaar worden
|
|
|
|
Concreet:
|
|
- browse van `/Volumes` retourneert een samengestelde directorylisting op basis van toegestane roots
|
|
- navigatie naar `/Volumes/<naam>` is alleen geldig als die volledige path overeenkomt met een geconfigureerde root of daarbinnen valt
|
|
|
|
Passend bij bestaand model:
|
|
- alle verdere padresolutie onder `/Volumes/8TB/...` en `/Volumes/8TB_RAID1/...` blijft via bestaand `path_guard`
|
|
- traversal en whitelistcontrole blijven dus centraal gehandhaafd
|
|
|
|
---
|
|
|
|
## 5. Backend-impact
|
|
|
|
Dit kan niet netjes alleen frontend-side worden opgelost.
|
|
|
|
Waarom niet frontend-only:
|
|
- de bestaande browse-API verwacht een pad dat door de backend gevalideerd en opgelijst wordt
|
|
- als de backend `/Volumes` niet kent als geldige browsecontext, kan de frontend die laag niet betrouwbaar simuleren zonder speciale hardcoded clientlogica
|
|
- frontend-only zou ook de securitygrenzen vertroebelen, omdat de UI dan zelf een deel van de directorystructuur zou moeten faken
|
|
|
|
Backend-aanpassing is dus nodig.
|
|
|
|
Veiligste en simpelste richting:
|
|
- een kleine backend-uitbreiding in de browse-service/path-interpretatie
|
|
- introduceer een gecontroleerd browse-niveau voor `/Volumes`
|
|
- behandel dat niveau als speciale, beperkte listing van geconfigureerde roots
|
|
- behoud voor alle onderliggende operaties het bestaande whitelist/path_guard-model
|
|
|
|
Pragmatische v1-richting:
|
|
- voeg een expliciete conceptuele container-root toe, bijvoorbeeld browsepad `/Volumes`
|
|
- browse op `/Volumes` retourneert alleen directory-entries voor de toegestane mount-roots
|
|
- browse op `/Volumes/<mount>` mapt naar de bestaande geconfigureerde root
|
|
|
|
Dat is veiliger dan `/Volumes` volledig als nieuwe whitelist-root toevoegen.
|
|
|
|
---
|
|
|
|
## 6. Risico's
|
|
|
|
### Regressierisico
|
|
- browse-contract moet duidelijk blijven voor bestaande paden zoals `storage1/...`
|
|
- bestaande UI- en golden-tests zijn nu alias-gebaseerd; die mogen niet onbedoeld breken
|
|
- copy/move/rename/delete/bookmarks werken nu op bestaande padrepresentaties; migratie naar `/Volumes/...` moet doordacht gebeuren
|
|
|
|
### Securitygevolgen
|
|
- een onzorgvuldige implementatie zou per ongeluk meer van `/Volumes` kunnen tonen dan toegestaan
|
|
- een onzorgvuldige mapping van `/Volumes/<naam>` naar echte paden kan whitelistcontroles verzwakken
|
|
|
|
### UX-verwarring
|
|
- tijdelijke co-existentie van aliaspaden (`storage1/...`) en hostachtige paden (`/Volumes/8TB/...`) kan verwarrend zijn
|
|
- zonder heldere keuze ontstaat een hybride model dat lastig te begrijpen en te testen is
|
|
|
|
---
|
|
|
|
## 7. Aanbeveling
|
|
|
|
Aanbevolen implementatierichting voor v1:
|
|
|
|
1. Niet frontend-only doen.
|
|
2. Geen vrije browse-root van heel `/Volumes` toevoegen.
|
|
3. Wel een gecontroleerde backend-browseweergave voor `/Volumes` introduceren.
|
|
4. Laat die weergave alleen expliciet geconfigureerde mountdirectories tonen.
|
|
5. Houd alle echte padvalidatie en verdere navigatie onder die mounts via bestaand `path_guard`-model.
|
|
|
|
Concreet aanbevolen model:
|
|
- `/Volumes` wordt een speciale browse-entrypoint
|
|
- listing van `/Volumes` bevat alleen de whitelisted mountnamen
|
|
- `/Volumes/8TB/...` en `/Volumes/8TB_RAID1/...` worden daarna normaal browsebaar binnen de bestaande veiligheidsgrenzen
|
|
|
|
Waarom dit de beste v1-richting is:
|
|
- sluit aan op de echte hoststructuur
|
|
- behoudt securitycontrole centraal in backend
|
|
- vermijdt frontend-hardcoding als primaire oplossing
|
|
- is beperkt, uitlegbaar en testbaar
|
|
|
|
Niet aanbevolen voor v1:
|
|
- puur frontend-aliasing
|
|
- volledig openstellen van `/Volumes` als generieke root
|
|
- tegelijk zowel aliasmodel als hostpathmodel als primaire UX blijven promoten zonder expliciete migratiekeuze
|