Mens jeg har holdt på å fikse Nikita-implementasjonen til å bli mer robust og komplett, så har jeg observert at det finnes tre mekanismer implementert i Nikta for å oppdatere registrert arkivinformasjon.
PUT ---
Her forventes det at en skal hente først med GET, endre felt og verdier en ønsker å endre, fjerne _links (med mindre en ønsker flytte oppføringen) og så gjøre PUT mot samme endepunkt. Jeg tror alle endepunkter nå støtter PUT, men det er mangelfull håndtering av feltsletting og forsøk på endring av verdier som ikke kan endres. Så vidt jeg kan forstå vil forsøk på å endre skrivebeskyttede verdier i dag ignoreres og sletting av tekst/tall-felt ignoreres, mens sletting av metadata-felt fører til intern feil i Nikita. N5TG spesifiserer denne, og dette var opprinnelig metode i N5TG for oppdatering av informasjon via API-et. Her må API-mottaket sammenligne innsendt informasjon med informasjonen i arkivet for å finne ut om et felt skal oppdateres eller ikke.
PATCH med JSON-instrukser (RFC 6902) ------------------------------------
Her gir en instrukser i JSON-format (add/move/etc) om hva en ønsker endre, som så gjennomføres av Nikita. Dette er ikke tilgjengelig for alle endepunkt, og så vidt jeg kan se har den ikke god kontroll med hvilke felt som er skrivebeskyttet og hvilke som kan oppdateres. Med bruken av PATCH er det kun informajson om felt som skal endres som sendes over, hvilket gjør det enklere for mottaker å vite intensjon. Mekanismen var en kandidat til å komme inn i N5TG, og ble implementert i Nikita for å teste ut dette, men ble til slutt valgt bort til fordel for
PATCH med JSON merge-last (RFC 7396) ------------------------------------
Her gir en JSON-format med de feltene som skal erstattes, tilordner dem 'null' hvis de skal slettes, og nikita oppdaterer så aktuelle felt. Dette er tilgjengelig for alle endepunkt og har så vidt jeg kan se god kontroll over skrivbarhetsstatus og sletting av felt. Denne mekanismen er lagt til N5TG som et alternativ til N5TG til bruk av PUT. Også her er det enklere å forstå intensjon med en endringsforespørsel enn PUT.
Anbefaling ----------
Jeg tenker det er opphav til kaos å ha flere ulike mekanismer for å oppdatere informasjon i arkivet, spesielt når det er ulike implementasjoner med potensielt litt forskjellig oppførsel. JEg tenker det også gjør livet vanskeligere for API-klienter som må forholde seg til flere mulige mekanikker og ikke nødvendigvis vet hvilken som bør brukes når.
Jeg tenker derfor at oppdatinging ved bruk av PATCH med JSON-instrukser RFC 6902 og PUT bør droppes fra både Nikita og N5TG, slik at det kun er en mekanisme igjen og vi kan konsentere innsatsen om å gjøre denne så robust og korrekt som mulig.
Jeg tenker videre at selv om N5TG fortsatt nevner PUT som en mulighet, så bør Nikita dokumentere at denne muligheten ikke eksisterer i Nikita og at en i stedet må bruke PATCH i tråd med RFC 7396 for alle endringer. Det kan ta litt tid å få PUT ut av N5TG, men jeg tror Nikita ikke bør vente på dette før en reduserer kodebase og angrepsflate ved å fjerne PUT-støtte.
Hva tenker dere andre?
[Petter Reinholdtsen]
Jeg tror alle endepunkter nå støtter PUT, men det er mangelfull håndtering av feltsletting og forsøk på endring av verdier som ikke kan endres.
Mens jeg venter på respons på om PUT kan droppes, har jeg fått sludderboten min til å lage <URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/620 > som endrer oppførel på PUT til å være mer som jeg tolker N5TG, og slik gjør PUT mindre mangelfull, kanskje til et nivå der den er korrekt implementert.
Jeg tolker N5TG diten at PUT skal motta det samme som GET returnerte, og alle felt og verdier (bortsett fra _links) som er forsvunnet fra det GET returnerte skal forsøkes slettes med PUT-forespørselen. Det er ikke slik PUT oppfører seg i dag, der det at en attributt fjernes fra JSON ganske enkelt blir ignorert. Dette endringsforslaget er altså et alternativ til å slette PUT-støtte. Jeg anbefaler som nevnt tidlgiere å droppe PUT fra både Nikita og N5TG, men tenkte det var greit å ta valget mens alternativene PUT og merge PATCH er på like fot.
Hva tenker dere andre?
Hei,
Jeg støtter Petters forslag om å konsolidere til én oppdateringsmekanisme. Flere parallelle mekanismer med litt ulik oppførsel er en oppskrift på inkonsistens, både i Nikita-kodebasen og hos API-klienter som må gjette hvilken metode som er «den riktige». PATCH etter RFC 7396 virker som det beste valget: klienten uttrykker intensjon eksplisitt (felter som skal endres, null for felter som skal slettes), og mottaker kan håndheve skrivebeskyttelse felt for felt uten å måtte sammenligne hele objektet slik PUT krever. At PUT i dag stille ignorerer forsøk på å endre skrivebeskyttede verdier er i seg selv et argument for å fjerne den – stille ignorering av klientens intensjon er verre enn en tydelig feilmelding.
Samtidig vil jeg løfte et beslektet tema: sletting.
Hva med HTTP/1.1 DELETE i Nikita-implementasjonen av arkivstandarden Noark 5?
Et arkiv hvor informasjon også kan slettes av arkivaren ved feil i arkivering alene uten sporbarhet er vel ikke et lovlig arkiv?
Tenk på hvor ufritt samfunnet hadde blitt hvis vi som innbyggere ikke kunne slette egen feiloppført misinformasjon fra Facebook, Twitter, Instagram, og tilbakekalle meldinger fra Outlook. Vi ser problemet hos TruthSocial hvor sletting av offentlige uttalelser og på hackede kontoer ikke er mulig.
For forvaltningen er spørsmålet om det skal finnes en sletteknapp til arkivarer for feiloppført informasjon med aksesskontroll for entiteter og autentiserte identiteter, og en strategi for sletting ved datainnbrudd og brudd på integritet.
Jeg har tidligere lurt på hvorfor et Noark-arkiv ikke bare kan tilby HTTP DELETE for arkivaren ved feilarkivering. Svaret er selvsagt at arkivlova § 9 forbyr kassasjon uten hjemmel, og at et arkiv der enkeltpersoner ensidig kan fjerne dokumentasjon ikke lenger er et troverdig arkiv – det beskytter borgeren mot forvaltningen like mye som omvendt. Men behovet bak spørsmålet er reelt: feilarkivering skjer, og GDPR-sletting og kassasjonsvedtak er lovpålagte prosesser.
Noark 5 har allerede de kontrollerte stiene for dette: status «Utgår» ved feilregistrering, kassasjon med hjemmel, og sletting etter personopplysningsloven (med unntakene i GDPR art. 17(3)(b) og (d) i mente). Mitt innspill er at når vi først konsoliderer endrings-API-et, bør disse slettestiene få førsteklasses, veldokumentert API-støtte i Nikita:
- Setting av status «Utgår» via PATCH (RFC 7396) på statusfeltet, med tilgangskontroll på hvem som kan gjøre det. - Egne, eksplisitte endepunkter eller operasjoner for kassasjon og GDPR-sletting, der selve slettehandlingen logges med hjemmel, tidspunkt og autentisert identitet. - Dokumentasjon som gjør det tydelig for klientutviklere at DELETE på arkiverte ressurser ikke finnes, og hva de skal bruke i stedet – på samme måte som Petter foreslår å dokumentere at PUT ikke eksisterer i Nikita.
Da får arkivaren i praksis «sletteknappen» sin ved feilarkivering, men med revisjonsspor og aksesskontroll – og API-et blir ærlig om hva som faktisk er mulig, i stedet for å la klienter prøve seg frem.
Kort oppsummert: +1 til å fjerne PUT og RFC 6902-PATCH fra Nikita (og på sikt N5TG), og et ønske om at kontrollert sletting løftes frem som del av samme opprydding.
Mvh, Ole Aamot
On Thu, Sep 3, 2026 at 9:51 PM Petter Reinholdtsen pere@hungry.com wrote:
Mens jeg har holdt på å fikse Nikita-implementasjonen til å bli mer robust og komplett, så har jeg observert at det finnes tre mekanismer implementert i Nikta for å oppdatere registrert arkivinformasjon.
PUT
Her forventes det at en skal hente først med GET, endre felt og verdier en ønsker å endre, fjerne _links (med mindre en ønsker flytte oppføringen) og så gjøre PUT mot samme endepunkt. Jeg tror alle endepunkter nå støtter PUT, men det er mangelfull håndtering av feltsletting og forsøk på endring av verdier som ikke kan endres. Så vidt jeg kan forstå vil forsøk på å endre skrivebeskyttede verdier i dag ignoreres og sletting av tekst/tall-felt ignoreres, mens sletting av metadata-felt fører til intern feil i Nikita. N5TG spesifiserer denne, og dette var opprinnelig metode i N5TG for oppdatering av informasjon via API-et. Her må API-mottaket sammenligne innsendt informasjon med informasjonen i arkivet for å finne ut om et felt skal oppdateres eller ikke.
PATCH med JSON-instrukser (RFC 6902)
Her gir en instrukser i JSON-format (add/move/etc) om hva en ønsker endre, som så gjennomføres av Nikita. Dette er ikke tilgjengelig for alle endepunkt, og så vidt jeg kan se har den ikke god kontroll med hvilke felt som er skrivebeskyttet og hvilke som kan oppdateres. Med bruken av PATCH er det kun informajson om felt som skal endres som sendes over, hvilket gjør det enklere for mottaker å vite intensjon. Mekanismen var en kandidat til å komme inn i N5TG, og ble implementert i Nikita for å teste ut dette, men ble til slutt valgt bort til fordel for
PATCH med JSON merge-last (RFC 7396)
Her gir en JSON-format med de feltene som skal erstattes, tilordner dem 'null' hvis de skal slettes, og nikita oppdaterer så aktuelle felt. Dette er tilgjengelig for alle endepunkt og har så vidt jeg kan se god kontroll over skrivbarhetsstatus og sletting av felt. Denne mekanismen er lagt til N5TG som et alternativ til N5TG til bruk av PUT. Også her er det enklere å forstå intensjon med en endringsforespørsel enn PUT.
Anbefaling
Jeg tenker det er opphav til kaos å ha flere ulike mekanismer for å oppdatere informasjon i arkivet, spesielt når det er ulike implementasjoner med potensielt litt forskjellig oppførsel. JEg tenker det også gjør livet vanskeligere for API-klienter som må forholde seg til flere mulige mekanikker og ikke nødvendigvis vet hvilken som bør brukes når.
Jeg tenker derfor at oppdatinging ved bruk av PATCH med JSON-instrukser RFC 6902 og PUT bør droppes fra både Nikita og N5TG, slik at det kun er en mekanisme igjen og vi kan konsentere innsatsen om å gjøre denne så robust og korrekt som mulig.
Jeg tenker videre at selv om N5TG fortsatt nevner PUT som en mulighet, så bør Nikita dokumentere at denne muligheten ikke eksisterer i Nikita og at en i stedet må bruke PATCH i tråd med RFC 7396 for alle endringer. Det kan ta litt tid å få PUT ut av N5TG, men jeg tror Nikita ikke bør vente på dette før en reduserer kodebase og angrepsflate ved å fjerne PUT-støtte.
Hva tenker dere andre?
Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no
[Ole Aamot]
Kort oppsummert: +1 til å fjerne PUT og RFC 6902-PATCH fra Nikita (og på sikt N5TG),
Da er vi enige der.
og et ønske om at kontrollert sletting løftes frem som del av samme opprydding.
Jeg er ikke interesert i å blande sammen ønsket om entydig støtte for oppdatering med sletting. Det er to separate spørsmål som bør håndteres uavhengig av hverandre, og PATCH/PUT er allerede komplekst nok å finne løsning på. Når det er sagt, så støtter N5TG og Nikita DELETE for tilstrekkelig priviligerte brukere (naturligvis, hvordan skulle en ellers skulle flytte fra en implementasjon til en annen), så jeg mistenker det som trengs er erfaring og dokumentasjon, men det tenker jeg eventuelt hører hjemme i en annen tråd.
Mens jeg venter på tilbakemeldinger så har jeg fått laget <URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/621 > som fjerner støtten for RFC 6902 type JSON Patch-oppdateringer.
Den beskriver hvilke entiteter som støttet slike oppdateringer og viser hvor mye kode som må fjernes.