sysopsandClaude Sonnet 5
3d5f53f103
internal/policy/module_scope.go: policy_module_scopes verknuepft optional eine (role, permission)-Regel mit einem LIC-02-Feature-Flag. Enforcer. AuthorizeForTenant ist DIESELBE zentrale Entscheidungsfunktion wie Authorize (Akzeptanzkriterium 3, kein zweiter Enforcement-Mechanismus) — prueft zusaetzlich zur Grundregel, ob das verknuepfte Modul fuer den Tenant aktiv ist. Existiert kein ModuleScope-Eintrag, bleibt eine Regel wie bisher ohne Lizenzbindung gueltig (Kombinationsfall). GuardModuleScoped erweitert policy.Guard um dieselbe Pruefung. internal/flag (LIC-02) wurde 1:1 aus dem lic-02-Branch uebernommen (git show aus derselben Repo-Historie, keine Aenderung) — RBAC-04 haengt sowohl an RBAC-01/02 als auch an LIC-02, aber diese leben auf getrennten, noch nicht gemergten Feature-Branches ohne gemeinsame Historie. Fail-Safe-Verhalten aus LIC-02 greift automatisch: ein nicht konfiguriertes oder nicht erreichbares Feature-Flag gilt als deaktiviert, nie als aktiviert (sicherer Default fuer Modul-Aktivierungspruefungen). Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Zugriff auf deaktiviertes Modul trotz passender Rolle abgewiesen — TestAuthorizeForTenant_DeniesWhenModuleNotActivated: GuardModuleScoped ruft die Query-Funktion nachweislich nicht auf. PASS. 2. Reaktivierung macht Berechtigung im laufenden Betrieb wirksam, kein Neustart — TestAuthorizeForTenant_BecomesActiveWithoutRestart: derselbe Enforcer/Service-Prozess, Flag per Store.Set aktiviert, TTL abgewartet, danach erlaubt. PASS. 3. Zusammenspiel Modul-Scope + Rollenscope in Kombinationsfaellen — TestAuthorizeForTenant_CombinationsOfRoleAndModuleScope: keine Regel -> verboten; Regel ohne Modul-Scope -> immer erlaubt; Regel mit Modul-Scope und Flag aus -> verboten; Flag an -> erlaubt. PASS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 lines
36 B
SQL
2 lines
36 B
SQL
DROP TABLE IF EXISTS feature_flags;
|