Tilpasninger for å støtte requests til spesifikke layers basert på url/context

[anders-nom]

Bakgrunnen her er at vi ønsker å tilgjengeliggjøre layers-lokaliserte filer til publikum. Det har vært to problemer med dette:

1. Vi har hittil mappet alle requests til default-repoet via vhosts. Dette har fungert for service-kall, siden vi har implementert layers via context api'et i servicene som har behov for det. For filer derimot har vi ikke mulighet til å gjøre egne tilpasninger, så her må vi sette context til ønsket layer via request url.
2. Når vi først satte opp layers, ønsket vi ikke at disse skulle være synlige for alle redaktører. Derfor satte vi repoene for disse som private, kun tilgjengeliggjort for enkelte roller. Problemet er at dette også påvirker tilgangsstyring for requests fra publikum. Innhold må i utgangspunktet være tilgjengelig for everyone for å kunne serveres til uinnloggede brukere. Å endre på denne tilgangsstyringen nå vil kreve en re-publisering av alt innhold, som hadde vært en ganske kjip oppgave, ettersom vi da må ta høyde for avpublisert eller upublisert innhold i layer'ene.

1 løses med vhost mappinger til hvert layer repo. 2 løses ved å gi en midlertidig request-spesifikk innloggingssesjon for uinnloggede brukere som request'er en publisert fil.

Se også navikt/nav-enonicxp-frontend#2014

Oppsummering av hva som er gjort

• Setter opp en egen idprovider for nav.no appen. Vi mapper denne til layers-spesifikke requests via vhosts. Denne idprovider'en gir automatisk gir en request-spesifikk innloggingssesjon for uinnloggede brukere dersom requesten er for en publisert fil.
• Tilpasser cacher for publikums-tilgjengelige services for å støtte requests til ulike repoer/branches
• Strammer inn permissions for services, slik at kun brukere med admin-login rolle har tilgang. Litt forvirrende navn på roller fra Enonic sin side her, system.admin betyr faktisk administrator, men system.admin.login betyr bare at du kan logge inn i "admin"-UI'et (dvs portal-admin) 😅.
• Fjerner ubrukt service for layers migrering

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud