Skal tjenestegrensesnittet bruke '$ref?$id' ?

[Thomas Sødring]

Hei,

Tjenestegrensesnittet forventer at klienter skal bruke '$ref?$id' der 
det er snakk om operasjoner på koblinger på tvers av arkivenheter. For 
det meste er tjenestegrensesnittet en CRUD beskrivelse og da ser vi på 
individuelle instanser av arkivenheter. I noen tilfeller er det behov 
for å jobbe med arkivenheter der vi er mer opptatt av lenker. Dette kan 
feks være å flytte en mappe fra en arkivdel til en annen arkivdel. Det 
er fremmednøkler operasjonen går på framfor attributter. En annen 
eksempel er referanseForloeper til arkivdel, heller kryssreferanser. 
Disse er opptatt av fremmednøkler i databasen.

Jeg synes beskrivelsen av slike operasjoner er litt dårlig i 
tjenestegrensesnittet, men det kom inn på et tidspunkt der man mente 
"$ref?$id=https://..." var en bra måte å identifisere arkivenheter på. I 
nikita prosjektet har vi ønsket å gå bort fra $ref?$id tilnærmingen 
fordi det anses å være en sikkerhetsrisiko å akseptere tilleggs URLer på 
som en del av http forespørsel. Jeg fant ut av det da spring-boot kastet 
forespørsler der request parameters inneholdt ":" og etter litt 
debugging så var det pga "https://". Se [1], [2].

Et viktig prinsipp vi har fulgt i nikita er at kjernen kan og skal lett 
identifisere et objekt gitt en systemID. Dette er viktig fra et 
innsynsperspektiv men også et sporings- og kontrollperspektiv. Tenk deg 
et depot institusjon som bruker nikita som innsynsløsning og har flere 
hundre uttrekk. Da hadde det vært fint å kunne spørre arkivkjernen "Hva 
er denne UUID d7418b5c-0bb3-4b09-9312-48a7745d2c97 for noe?" og få 
tilbake at det er en saksmappe fra Oslo kommune. Et slikt endepunkt i 
nikita kan enkelt implementeres med et endepunkt som ser slik ut:


https://nikita.example.com/noark5v5/api/arkivstruktur/d7418b5c-0bb3-4b09-9312-48a7745d2c97 


Dette er noe jeg ønsker å sende endringsforslag til 
tjenestegrensesnittet på. Jeg har avventet så langt fordi jeg ville ha 
en bedre implementasjonsforståelse av hvordan dette treffer helheten i 
tjenestegrensesnittet men tror nå at det bør la seg fint gjennomføre. 
Før jeg utvikler endringsforslag for de forskjellige arkivenhetene vil 
jeg legge ut en beskrivelse her så dere som ønsker kan kommentere.

Dersom noen har meninger om bruken av URLer i HTTP request parameters, 
eventuelt at de synes det er en god ide så vil jeg gjerne diskutere det.

  - Thomas

[1] https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/
[2] 
https://docs.spring.io/spring-security/site/docs/4.2.20.RELEASE/apidocs/org/springframework/security/web/firewall/StrictHttpFirewall.html