Funksjonaliteten i Spine blir gjort tilgjengelig via Corba. Alle metodene blir wrappet av _create_corba_method i spine/lib/server/Corba.py før de blir gjort tilgjengelig. En av tingene som blir gjort her er at metoden transaction.authorization.check_permission blir kjørt. Dersom denne feiler, så blir ikke den opprinnelige metoden kjørt. Så vidt jeg vet blir absolutt alle metodene som blir gjort tilgjengelig for spineklienten wrapper på denne måten, altså er det umulig å unngå at et metodekall blir autorisert før det blir kjørt.

Variabelen transaction.authorization blir satt av spine/lib/server/Session.py og er per i dag satt til spine/lib/server/Authorization.py. Dersom kallet av check_permission feiler, blir det kastet en AccessDenied exception. Dersom det går gjennom blir metoden kjørt.
[rediger]
check_permission

Vi vil gjerne at mesteparten av autorisasjonsoppsettet kan gjøres via databasen og definerte tilgangsnivå, men endel ting må hardkodes. Her er en enkel skisse av hva som må skje i check_permission foregår:

   1. Er det en superbruker som vil utføre operasjonen? True = Success.
   2. Har alle tilgang til å utføre operasjonen? True = Success.
   3. Vil operasjonen kunne eskalere brukerens rettigheter? True = FAILURE
   4. Har operasjonen en egen autorisasjonshåndterer?
   5. Har objektet en egen autorisasjonshåndterer?
          * FIXME: Hvordan skal vi gjøre dette? Skal disse to ta over fullstendig eller skal vi fortsette med resten dersom False?
          * FIXME: Vi må definere et interface.
          * FIXME: Trenger vi begge deler eller holder det med den ene? Eller trenger vi dette i det hele tatt? 
   6. Er operasjonen tilgjengelig for eieren av objektet?
         1. Er brukeren eier av objektet? True = Success.
         2. Er eieren en gruppe?
               1. Er brukeren medlem av gruppen? True = Success. 
   7. Har brukeren tilgang til å utføre operasjonen som konsekvens av tilgangsnivå?
         1. Har brukeren tilgang til objektet som følge av tilknytning? True = Success.