Fælles udgiver, separate kundegrants
En partnerapp kan bruges af flere butikker eller selskaber. Appen og dens review er fælles, men produktionsadgangen gives gennem konkrete grants. Hver grant har egen organisation, scopes, kontoreferencer, udløb og autoriserende aktør.
Gem disse relationer i dit integrationssystem uden at gøre et vilkårligt kundesendt ID til adgangskontrol. Et eksternt butiksnummer skal mappes til den grant, der faktisk blev autoriseret, og mappingen skal kunne tilbagekaldes eller revideres.
Hovedkontor er ikke automatisk adgang til alle
Et HQ- eller regionstilhørsforhold kan være relevant i produktets rettighedsmodel. Det beviser ikke, at en person må give en ekstern app adgang til alle underliggende selskaber. Samtykkeflowet kræver en aktuel ejerrelation til den valgte organisation.
Partner-API'et tilbyder ikke et "all organizations"-scope. En anmodning om det afvises og oversættes ikke til en liste over alle medlemsorganisationer. Udvikleren får heller ikke alle kunders identiteter ved at logge ind i sit workspace.
Kontomapping pr. enhed
To virksomheder kan bruge samme kontonummer med forskellig konfiguration, og de har forskellige UUID-referencer. En mapping skal derfor have organisation og miljø som kontekst. Den må ikke genbruges blindt, fordi kontonummeret ser bekendt ud.
Ved en ny grant skal integrationen kontrollere det udvalgte kontosæt igen. En tidligere valgt reference er ikke permanent gyldig, hvis kundens rettigheder eller apprevisionen er ændret.
Konsolroller og kundens roller
Udgiverens udvikler, workspace-admin og viewer styrer adgang til appkonfigurationen. De er ikke automatisk regnskabsbrugere i nogen kundeorganisation. Omvendt er kundens ejer ikke automatisk administrator i partnerens udviklerarbejdsrum.
Den adskillelse skal også være tydelig i support. En supportmedarbejder må ikke få brede kundedata blot for at fejlfinde et appsecret. Ofte er request-ID, apprevision og en minimal kvittering nok til at afklare, hvor fejlen opstod.
Test med mindst to enheder
Brug to isolerede testorganisationer med hver sine konti. Test samtidig trafik, forkert mapping, cursor fra en anden kontekst, delvis tilbagekaldelse og en partnerarbejder, der genstarter med en forældet "aktiv kunde". Kontrollér både dataoperationer og UI, så et forsinket svar ikke vises under den forkerte kunde.
Et flow, der fungerer med én testvirksomhed, beviser ikke flerorganisationssikkerhed. Organisationskontekst og kundetilslutning beskriver den konkrete model.