Rettighedskataloget
| Scope | Tilladt handling | Giver ikke adgang til |
|---|---|---|
configuration:read | Kundens udvalgte kontoreferencer | Hele kontoplanen, kontosaldi eller bankkonti |
journal:prepare | Valideret forberedelse af et journalinput | Bogføring eller fri læsning af hovedbogen |
journal:post | Endelig postering med særskilt mandat | Storno, udbetaling eller anden organisations bog |
journal:read | Organisationens bogførte posteringer, kun linjer på tildelte konti | Linjer på andre konti, bankfelter eller bankafledte oplysninger |
products:write | Opret et produkt | Opdatér eller slet et eksisterende produkt |
products:read | Organisationens produkter | Bank- og betalingsfelter |
invoices:write | Opret en fakturakladde | Udsted, send eller markér en faktura betalt |
invoices:read | Organisationens salgsfakturaer | Bank-, betalings-, afsender-bankkonto- eller Stripe-felter |
operations:read | Egen operationskvittering | Andre apps' hændelser eller generel revisionslog |
Scopes er bogstavelige, case-sensitive strenge. Der er ingen wildcardscope og intet bank:*. Ukendte eller gentagne scopes afvises. Oplys ikke en rettighed, der ikke findes i kataloget, i håb om at serveren senere fortolker den.
Hvorfor skrive- og læseadgang er adskilt
En integration kan have behov for at oprette en fakturakladde fra sit eget ordresystem uden at kunne læse kundens øvrige fakturaer. I det tilfælde er invoices:write tilstrækkeligt, og appen behøver ikke invoices:read. Svaret er en minimal kvittering, ikke en fuld intern fakturarække med data, appen ikke indsendte.
Det gælder også konflikter og upsert. Hours' eksisterende modpartsfunktion kan ved CVR-dubletter returnere en eksisterende fuld modpart. En sådan genvej er ikke en skrive-only partneroperation. At HTTP-metoden hedder POST, gør ikke alle data i svaret lovlige at udlevere.
Et skrivegrant skal stadig kunne begrænses og tilbagekaldes. "Ingen læseadgang" betyder ikke "ufarlig integration": en forkert postering eller tusind dublerede produkter kan skade kundens arbejde uden at lække data. Derfor gælder inputkontrol, idempotens, kvoter, mandat og revisionsspor også ved write-only.
Kontoreferencer er en afgrænset afhængighed
Journalposteringer skal referere til rigtige konti. Kunden vælger højst 200 kontoreferencer ved autorisationen. configuration:read kan udlevere id, kontonummer og navn for netop disse aktive konti, men ingen saldi. Det gør en skriveintegration brugbar uden at åbne hele regnskabet.
Ved bogføring kontrolleres kontoens kunde- og organisationsejerskab igen. Et UUID, der er gyldigt i en anden organisation, er ikke en gyldig reference i denne. Momskoder og dimensioner valideres ligeledes mod den konkrete organisation. Der er ikke en generel ekstern referencekatalogservice til disse områder; testdata og kundeopsætning skal derfor være afklaret, før de medsendes.
Et grant tilhører én organisation og én revision
Et kundegrant indeholder app-id, apprevision, organisation, autoriserende ejer, scopes, kontoreferencer, tidspunkt, udløb og eventuel tilbagekaldelse. Grantet gives af organisationsejeren med tofaktor (AAL2), og udløb kan vælges fra 1 til 90 dage.
Et token er bundet til dette grant. Klienten må ikke sende en anden organisations-id for at skifte kunde. En integration til flere virksomheder skal have flere eksplicitte forbindelser og holde tokens og lokale synkroniseringsmarkører adskilt. Kædeadgang eller medlemskab hos en udgiver er ikke en genvej til alle butikkers eller kunders data.
Apprevisionen er en del af sikkerhedsbeslutningen. En profilændring tilbagekalder tidligere grants og tokens og kræver ny godkendelse. Kundens seneste accept bliver ikke automatisk udvidet til en ny redirectadresse eller et større scopekatalog.
Ejer, udvikler og reviewer
Udviklerarbejdsrummets ejer administrerer appteamet. Kundens organisationsejer autoriserer data- og skriveadgang. Hours' reviewer træffer appreviewbeslutningen. En person kan have flere roller i forskellige sammenhænge, men handlingerne forbliver separate.
Revieweren skal have en faktisk intern staffrolle, AAL2 og være uafhængig af appens arbejdsrum og opretter. Kundens grant kræver en faktisk ejerrelation til den valgte, aktive organisation og AAL2. Klientens metadata, skjulte formularfelter og user-editable profilfelter bruges ikke som bevis for staff eller ejeradgang.
Hvad afvises, selv med et gyldigt scope?
Adgang stoppes ved forkert miljø eller resource, udløbet token, udløbet eller tilbagekaldt grant, suspenderet app, ændret reviewrevision, ugyldig ejerrelation. Et validt token betyder således ikke, at alt fortsat er tilladt i hele tokenets levetid.
Der er intet separat tjek af et produktmodul. For læsning er adgangen begrænset til organisationens bogførte posteringer på de tildelte konti, produkter og salgsfakturaer, uden bank-, betalings-, afsender-bankkonto- eller Stripe-felter. Anden kundelæsning er ikke en partneroperation.
Læs bankafgrænsningen og tilbagekaldelse før produktionsaktivering. En ny kontrol i UI'et kan ikke erstatte en serverkontrol på hver faktisk adgangsvej.