Roller ve izinler

Cluster ERP istekleri rol tabanlı erişim denetimiyle yetkilendirir: kullanıcı rollere sahiptir, rol izin kodlarına sahiptir ve bir uç bir veya daha çok kod ister. Bu sayfa modules/auth/permissions içindeki izin kataloğunu, modules/auth/roles içindeki rolleri, modules/auth/users içindeki kullanıcı rol atamasını, modules/auth/guards.py içindeki bekçiyi, server/permission_families.py içindeki aile ayrımlarını ve EventBus sözleşmelerindeki REQUIRED_PERMISSION desenini açıklar. Bir izni daraltan öznitelik politikaları ABAC politikaları sayfasında, alan ve satır sınırları alan ve satır erişimi sayfasındadır.

Kısaca¶

• Bir izin kodu <resource>.<action> biçimindedir. Her açılışta modül metadata'sındaki her varlık ve ayar sekmesi için create, read, update ve delete kodları ile sabit bir ek kod listesi tohumlanır (src/cluster_erp/modules/auth/permissions/services.py:44-136, src/cluster_erp/server/app.py:634-858).
• Kodu admin olan tek bir sistem rolü her açılışta güvenceye alınır ve her canlı izin ona yeniden verilir (src/cluster_erp/modules/auth/roles/services.py:213-276).
• Bir uç isteğini require_permission("<code>") ile bildirir; bekçi çağıranı doğrular, her kodun çağıranda olduğunu denetler, sonra öznitelik politikalarını değerlendirir (src/cluster_erp/modules/auth/guards.py:205-240).
• Verme işlemi tavanlıdır: çağıran, sistem yöneticisi rolünde değilse, yalnızca kodlarını zaten taşıdığı bir rolü veya izni ekleyebilir (src/cluster_erp/modules/auth/users/services.py:169-221, src/cluster_erp/modules/auth/roles/services.py:122-163).
• Bir kullanıcının izin kümesi, canlı kullanıcı rol bağları ve canlı izin atamaları üzerinden canlı izinlerin birleşimidir (src/cluster_erp/modules/auth/users/services.py:310-332).

Nasıl çalışır¶

Veri modeli¶

Atamalar asla silinmez. Bir kullanıcıdan rol veya bir rolden izin kaldırmak deleted_at basar; yeniden eklemek aynı satırı canlandırır (src/cluster_erp/modules/auth/users/services.py:161-181, src/cluster_erp/modules/auth/roles/services.py:115-134).

Kataloğun tohumlanması¶

_seed_permissions_from_metadata her yüklü modül için metadata'daki varlık anahtarlarını ve ayar bölümlerindeki sekme anahtarlarını toplar (src/cluster_erp/server/app.py:639-652). approve, install veya read_all gibi yaşam döngüsü eylemleri için bir ek kod listesi ekler (src/cluster_erp/server/app.py:654-848). seed_from_metadata eksik her kodu yaratır ve var olan bir kodu bugün varlığını bildiren modülün altına yeniden dosyalar (src/cluster_erp/modules/auth/permissions/services.py:44-136). Ardından ensure_system_admin her canlı izni admin rolüne verir, iptal edilmiş atamaları canlandırır ve eski bir system_admin rolünü onunla birleştirir (src/cluster_erp/modules/auth/roles/services.py:174-276). Sonra copy_family_grants çalışır (bkz. Aile ayrımları bölümü).

Bu commit'teki sayılar, kod okunarak yapılmıştır:

Bir veritabanındaki toplam kod sayısı yüklü modüllere ve metadata'larına bağlıdır; kodda sabit değildir.

İzin denetimi¶

Akış şeması require_permission bekçisinin bir istek için yaptığını gösterir.

flowchart TD
 req["korunan istek"] --> user["get_current_user"]
 user --> codes["auth_cache.permission_codes"]
 codes --> loop{"istenen her kod için"}
 loop --> held{"kod var mı?"}
 held -->|hayır| deny["permission_denied 403"]
 held -->|evet| abac["resource None ile check_abac"]
 abac -->|false| deny
 abac -->|true| loop
 loop -->|hepsi geçti| route["uç işleyicisi"]
 route --> post["yüklemeden sonra enforce_abac, yalnız bağlı kodlar"]

Düz anlatımla:

1. get_current_user çağıranı doğrular (src/cluster_erp/modules/auth/guards.py:212). Bkz. kimlik doğrulama ve oturumlar.
2. Çağıranın kodları kısa ömürlü bellekten gelir (src/cluster_erp/modules/auth/guards.py:213).
3. İstenen her kod için eksik bir kod permission_denied fırlatır: AUTH_PERMISSION_DENIED koduyla HTTP 403 (src/cluster_erp/modules/auth/guards.py:222-224, src/cluster_erp/core/errors.py:388-394).
4. check_abac kodun öznitelik politikalarını varlık olmadan değerlendirir; abac_strict_permission_codes içindeki kodlar politikası yoksa reddedilir (src/cluster_erp/modules/auth/guards.py:215-236).
5. Bazı servisler varlığı yükledikten sonra enforce_abac çağırır (src/cluster_erp/modules/auth/guards.py:284-303). Bkz. ABAC politikaları.

Uygulama hakkı iş modüllerinde ayrı bir yönlendirici bağımlılığıdır: require_app. Bkz. uygulama mağazası lisansları ve hakları.

Rol ve izin atama¶

Tavan AUTH_PRIVILEGE_ESCALATION koduyla privilege_escalation fırlatır ve eksik kodları listeler (src/cluster_erp/core/errors.py:397-405).

Aile ayrımları¶

Bir uç grubu ortak bir kod ailesinden kendi ailesine taşındığında FAMILY_SPLITS ana aileyi ve yeni aileleri adlandırır: 8 alt aileli sales_order ve 23 alt aileli fleet_asset (src/cluster_erp/server/permission_families.py:25-64). Açılışta copy_family_grants, ana kodu taşıyan her role eşleşen alt kodları bir kez verir; ACTION_GRANTS aynısını shipment.dispatch gibi yaşam döngüsü kodları için yapar (src/cluster_erp/server/permission_families.py:67-118).

Sözleşmelerdeki izin sözlüğü¶

EventBus üzerinden başka bir modülde iş başlatan bir uç, gereken kodu başka bir modülün kodunu yazmak yerine sözleşme sınıfından okur. CreateBomForProduct.REQUIRED_PERMISSION ve CreateProductionOrderForProject.REQUIRED_PERMISSION bu özniteliği taşıyan iki sözleşmedir (src/cluster_erp/core/contracts.py:1341-1346, src/cluster_erp/core/contracts.py:1361-1365). Çağıranları src/cluster_erp/modules/sales_orders/order_lines/routes.py:114 ve src/cluster_erp/modules/projects/items/routes.py:94-98 dosyalarıdır.

Neden böyle kurulmuştur¶

• Projenin yazılı mühendislik kuralları modüller arası doğrudan çağrıyı yasaklar; REQUIRED_PERMISSION başka bir modülün izin dizgisini çağırandan uzak tutar (src/cluster_erp/core/contracts.py:1341-1344).
• Kodun modül sahibi tohumlamada yeniden dosyalanır, çünkü eski bir sahip altında dosyalanmış kod rol kuran yöneticiye yanlış modülü gösteriyordu (src/cluster_erp/modules/auth/permissions/services.py:125-133).
• Verme tavanı, permission.assign veya user.update sahibinin kendi veya başka bir kullanıcının yetkisini yükseltememesi için vardır (src/cluster_erp/modules/auth/roles/services.py:122-125, src/cluster_erp/modules/auth/users/services.py:169-172).
• admin rolüne açılışta tüm kodlar yeniden verilir, çünkü açılıştan sonra her etkin izni taşıması gerekir (src/cluster_erp/modules/auth/roles/services.py:251-256).

Kurallar ve sınırlar¶

• Diğer modüller auth'tan yalnızca modules/auth/guards.py dosyasını içe aktarır: require_permission, get_current_user, permission_codes_for, actor_allowed ve role_ids_for (src/cluster_erp/modules/auth/guards.py:22-27, src/cluster_erp/modules/auth/guards.py:170-202).
• Bir kod geneldir. Bekçi kodu denetler, modülü asla denetlemez (src/cluster_erp/modules/auth/permissions/services.py:126).
• Kimlik doğrulayan ama kod istemeyen bir uç doğrudan get_current_user çağırır; örneğin onay gelen kutusu ve kullanıcının kendi arayüz durumu (src/cluster_erp/modules/auth/approvals/routes.py:35-53, src/cluster_erp/modules/auth/ui_state/routes.py:15-39).

Diğer parçalarla etkileşim¶

• auth modülü diğer modüller için GetUserPermissions sorgusunu yanıtlar (src/cluster_erp/modules/auth/module.py:82, src/cluster_erp/modules/auth/module.py:130-144).
• Metadata alanları ve aksiyonları bir izin kodu adlandırabilir; bkz. metadata modeli.
• Uygulama düzeyindeki rol atamaları (hangi rol hangi uygulamayı kullanabilir) ayrı bir katmandır; bkz. uygulama mağazası lisansları ve hakları.

Sınırlar ve açık noktalar¶

• Çalışan bir veritabanındaki izin kodu sayısı koddan belirlenemedi; yüklü modüllere bağlıdır (src/cluster_erp/server/app.py:642-652).
• Web uygulamasının genel rol formunun ötesinde bir izin düzenleyici sunup sunmadığı auth modülü metadata'sından belirlenemedi; orada bildirilen tek rol ekranı ROLE_META olur (src/cluster_erp/modules/auth/module.py:281-283).

Tanıtılan terimler¶

İlgili sayfalar¶

• Kimlik, erişim, kiracılık, gizlilik ve lisans
• ABAC politikaları
• Alan ve satır erişimi
• Auth modülü
• Sözleşmeler başvurusu

92f8051 numaralı commit ile 2026-11-13 tarihinde doğrulandı.