RBAC İzin Matrisi
Zeus 2.0, 77 granüler izin ve 3 önceden tanımlı rol içerir. Her rol, kaynak bazında farklı işlem yetkilerine sahiptir. İzinler ve rol şablonları tek kaynaktan tanımlanır: backend/app/core/security/permissions.py (Permission enum + ROLE_PERMISSIONS).
İzinler iki katmanda uygulanır: (1) Backend — her API isteği izin kontrolünden geçer (yetkisiz istek 403 Forbidden döner); (2) Frontend (UI) — kullanıcının izni olmayan menüler ve butonlar hiç çizilmez. İkinci katman güvenlik değil, kullanıcı deneyimidir (bkz. Frontend (UI) Gating).
Aşağıdaki roller firma (tenant) düzeyi yetkilendirmedir. Platform süper yöneticisi (is_superuser) bu izin kontrolünün dışındadır — tüm platform yetkilerine sahiptir ve firmalar arası (cross-tenant) Sistem Konsolu ekranlarını görür.
Roller
| Rol | Açıklama | İzin Sayısı |
|---|---|---|
| Admin | Tam yetki — tüm CRUD + yönetim işlemleri (mahsuplaşma yapısal yönetim dahil). | 77 |
| Operator | Okuma + sınırlı yazma (cihaz, gateway, alarm, iletişim) + OSOS senkron tetikleme + mahsuplaşma raporu yükleme. | 32 |
| Viewer | Salt okunur erişim (mahsuplaşma dahil yalnız görüntüleme). | 16 |
İzin Matrisi
Aşağıdaki tabloda her kaynak grubu için roller bazında verilen izinler listelenmiştir. Hücredeki kısaltmalar için Kısaltma Açıklamaları bölümüne bakın.
| Kaynak | İzin Tipleri | Admin | Operator | Viewer |
|---|---|---|---|---|
| Bölgeler (Regions) | READ, WRITE, DELETE | R W D | R | R |
| Alt Bölgeler (Subregions) | READ, WRITE, DELETE | R W D | R | R |
| Gateway'ler | READ, WRITE, DELETE | R W D | R W | R |
| Cihazlar (Devices) | READ, WRITE, DELETE, CONTROL (inverter) | R W D Ct | R W | R |
| Ölçümler (Measurements) | READ, EXPORT | R E | R E | R |
| Alarmlar | READ, WRITE, ACK, CLOSE | R W A C | R W A C | R |
| Alarm Politikaları | READ, WRITE, DELETE | R W D | R W | — |
| Raporlar | READ, WRITE, DELETE, EXPORT | R W D E | R E | R E |
| Ödemeler (Payments) | READ, WRITE, MANAGE (abonelik) | R W Sb | — | — |
| Kullanıcılar (Users) | READ, WRITE, DELETE | R W D | — | — |
| Roller (Roles) | READ, WRITE, DELETE | R W D | — | — |
| Varlıklar (Assets) | READ, WRITE, DELETE | R W D | R | R |
| SLD (Tek Hat Şeması) | READ, WRITE | R W | R | R |
| LOTO | READ, REQUEST, APPROVE, APPLY, RELEASE | R Rq Apr Ap Rl | R Rq Ap | R |
| Firmware † | READ, UPLOAD, DELETE | — | — | — |
| OTA † | READ, INITIATE, BATCH, ADMIN | — | — | — |
| İletişim Rehberi (Contacts) | READ, WRITE, DELETE | R W D | R W | R |
| Şarj İstasyonları (OCPP) | READ, WRITE, CONTROL, CONFIGURE, OTA, SECRETS | R W Ct Cf Ot Sc | — | — |
| Şarj İst. Modelleri (Charger Models) | READ, CREATE, UPDATE, DELETE | R Cr Up D | R | — |
| Tenant Ayarları (OCPP profil varsayılanları) | READ, UPDATE | R Up | R | — |
| OCPP Sürücüleri (Drivers) | MANAGE | M | — | — |
| OSOS Bağlantıları (DSO) | READ, WRITE, DELETE, SYNC | R W D Sy | R Sy | R |
| OSOS Toplu Yönetim | MANAGE (toplu alt bölge/sayaç) | M | — | — |
| Mahsuplaşma (Netting) | READ, MANAGE, IMPORT (rapor) | R M Im | R Im | R |
| Denetim (Audit) | READ | R | — | — |
Firmware ve OTA yönetiminin tamamı — firmware sürümü yükleme/yayınlama/kullanımdan kaldırma, tekil ve toplu OTA, rollback, takılan OTA temizliği — yalnızca platform süper yöneticisine açıktır ve Sistem Konsolu → Firmware · OTA (/console/firmware) altında toplanmıştır (bkz. Sistem Konsolu — Firmware · OTA).
Bu nedenle firma (tenant) düzeyi read:firmware / upload:firmware / delete:firmware / read:ota / initiate:ota / batch:ota / admin:ota izinleri hiçbir endpoint tarafından tüketilmiyor (inert) — matriste tüm roller için — gösterilir. İzinler enum'da (core/security/permissions.py) ve rol şablonlarında kaldırılmadan durur (fail-closed; ileride yeniden bağlanabilir), ancak bir uca erişim artık sağlamazlar. Bu izinlere sahip ama süper yönetici olmayan bir kullanıcı firmware/OTA uçlarına eriştiğinde 403 SUPERUSER_REQUIRED alır. (Not: cihazın firmware sürümü, cihaz detay ekranlarında salt-okunur görünmeye devam eder — bu bir yönetim işlemi değildir.)
Enum'daki bazı izinler ileriki fazlar için tanımlıdır ve henüz bir endpoint tarafından tüketilmiyor olabilir (ör. OSOS yönetim izinleri PR-5'e kadar dormant). Bu izinler ROLE_PERMISSIONS şablonlarına eklidir; matris kaynak koddaki güncel tanımı yansıtır.
Yukarıdaki dağılım, ROLE_PERMISSIONS içindeki varsayılan Admin / Operator / Viewer şablonlarını yansıtır. ROLE_PERMISSIONS yalnızca ilk kurulum (seed) sırasında okunur; çalışma zamanında izin kontrolü veritabanındaki role_permissions tablosundan yapılır. Bu nedenle bir firmada özel (custom) roller tanımlıysa ya da varsayılan roller sonradan düzenlendiyse, o rollerin izin seti bu matristen sapabilir. Bir rolün kesin/güncel izinlerini görmek için ilgili rolü Ayarlar → Roller ekranından inceleyin.
Kısaltma Açıklamaları
| Kısaltma | Açıklama |
|---|---|
| R | Read — Okuma / listeleme |
| W | Write — Yazma / güncelleme |
| D | Delete — Silme |
| E | Export — Dışa aktarma |
| A | Acknowledge — Alarmı onaylama |
| C | Close — Alarmı kapatma |
| Ct | Control — Cihaz/inverter/şarj kontrolü (RemoteStart-Stop, Reset vb.) |
| Cf | Configure — Şarj istasyonu yapılandırma (ChangeConfiguration, SetChargingProfile) |
| Ot | OTA (şarj) — Şarj istasyonu firmware güncelleme / diagnostik |
| Sc | Secrets — Şarj istasyonu parola döndürme + provisioning-kit indirme |
| Sb | Subscription — Abonelik yönetimi |
| U | Upload — Firmware yükleme |
| I | Initiate — OTA güncelleme başlatma |
| B | Batch — Toplu OTA |
| Ad | Admin — OTA yönetim (takılı işleri temizleme vb.) |
| Cr | Create — Oluşturma (model kataloğu) |
| Up | Update — Güncelleme (model / tenant ayarı) |
| Rq | Request — LOTO talebi oluşturma |
| Apr | Approve — LOTO onaylama |
| Ap | Apply — LOTO uygulama |
| Rl | Release — LOTO serbest bırakma |
| Sy | Sync — OSOS manuel senkron / bağlantı testi (canlı DSO isteği) |
| M | Manage — Tam yönetim (sürücü / toplu OSOS / mahsuplaşma yapısal CRUD = manage:netting) |
| Im | Import — Mahsuplaşma / uzlaştırma raporu yükleme (import:settlement_reports — GTŞ/LÜM/PYS) |
| — | İzin yok |
Frontend (UI) Gating
Yukarıdaki matris backend (sunucu) tarafında zorunlu kılınır: yetkisiz her API isteği 403 Forbidden ile reddedilir. Ancak Zeus 2.0 aynı izinleri arayüzde de uygular — yani izniniz olmayan bir menüyü hiç görmezsiniz, izniniz olmayan bir butonu ekranda bulamazsınız. Amaç, kullanıcıyı erişemeyeceği bir sayfaya tıklatıp 403 hatasıyla karşılaştırmak yerine, en baştan yalnızca yapabileceği işleri göstermektir.
Örnek: Viewer (salt-okuma) rolündeki bir kullanıcı, sol menüde "Ödemeler" ve "Şarj İstasyonları" girişlerini göremez; "Cihazlar" sayfasını açtığında ise "Yeni Cihaz", "Düzenle", "Sil" butonları hiç çizilmez — yalnız listeleme ve detay görüntüleme kalır.
Butonun gizli olması işlemi güvenli kılmaz. Gerçek koruma her zaman backend'dedir: bir kullanıcı butonu görmese bile isteği elle (ör. tarayıcı konsolu / API çağrısı) göndermeyi denese, backend izin kontrolü onu 403 ile durdurur. Frontend gating yalnızca kalabalığı azaltır ve deneyimi netleştirir. Bu nedenle hiçbir yetkilendirme kararı yalnız UI'a bırakılmaz.
Nasıl çalışır — izin çözümleme
Kullanıcı giriş yaptığında backend, /api/auth/me yanıtında kullanıcının izin listesini döner. Süper yönetici için bu liste sembolik bir joker (["*"]) içerir. Frontend, bu listeyi tek bir yardımcı (useHasPermission) üzerinden okur ve karar mantığı şudur (frontend/src/hooks/usePermissions.ts):
- Kullanıcı henüz yüklenmediyse → izin yok sayılır (öğe gizli kalır, yükleme bitince belirir).
- Kullanıcı
is_superuserise → her zaman izinli (tüm menü ve butonlar görünür). - İzin listesi joker (
*) içeriyorsa → her zaman izinli. - Aksi halde → izin, listede birebir var mı diye bakılır (ör.
write:device).
İzin adları backend'deki Permission enum değerleriyle birebir aynıdır ve eylem:kaynak biçimindedir (ör. read:device, write:alarm, manage:netting, read:report).
1. Sol menü (sidebar) gating
Sol menüdeki her giriş, bir gerekli izne bağlıdır. Kullanıcı o izne sahip değilse menü öğesi listeye hiç eklenmez (gizlenmez — DOM'a bile yazılmaz). Aynı kurallar hem masaüstü menüsünde (hierarchical-sidebar.tsx) hem mobil menüde (mobile-sidebar.tsx) birebir geçerlidir.
Aşağıdaki tablo, hangi iznin hangi menüyü açtığını gösterir (kod: menuConfig). "Viewer görür mü?" sütunu, salt-okuma rolünün o izne sahip olup olmadığını yansıtır.
| Menü öğesi | Gerekli izin | Viewer görür mü? |
|---|---|---|
| Dashboard | (koşulsuz — herkes) | ✅ Evet |
| Bölgeler | read:region | ✅ Evet |
| Gateway'ler | read:gateway | ✅ Evet |
| Cihazlar | read:device | ✅ Evet |
| Şarj İstasyonları | read:charger | ❌ Hayır (viewer'da yok) |
| OSOS / DSO | read:osos_connection | ✅ Evet |
| Ölçümler | read:measurement | ✅ Evet |
| Alarmlar | read:alarm | ✅ Evet |
| Raporlar | read:report | ✅ Evet |
| Ödemeler | read:payment | ❌ Hayır (viewer'da yok) |
| Mahsuplaşma | read:netting | ✅ Evet |
| Piyasa Fiyatları | read:netting | ✅ Evet |
| SLD | read:sld | ✅ Evet |
| LOTO | read:loto | ✅ Evet |
| WhatsApp Bridge | yalnız süper yönetici | ❌ Hayır |
| Sistem Konsolu | yalnız süper yönetici | ❌ Hayır |
| Ayarlar | (koşulsuz — herkes) | ✅ Evet* |
* Ayarlar menüsü herkese görünür; içerideki her sekme/kart kendi iznini ayrıca kontrol eder (bkz. Ayarlar sekmeleri).
Eski Firmware (read:firmware) ve Toplu OTA (batch:ota) sol menü girişleri
kaldırıldı; tüm firmware/OTA yönetimi Sistem Konsolu → Firmware · OTA
(/console/firmware, yalnız süper yönetici) altında toplandı. /admin/firmware ve
/admin/batch-ota yolları /console/firmwaree yönlendirir. Firma kullanıcıları
cihazın firmware sürümünü yine cihaz detayında salt-okunur görür, ancak firmware
yükleyip OTA başlatamaz.
Eski /users menü girişi kaldırıldı; kullanıcı yönetimi Ayarlar → Kullanıcılar sekmesine taşındı ve read:user iznine bağlıdır. Viewer bu izne sahip olmadığından sekmeyi göremez. (Süper yöneticinin firmalar-arası kullanıcı yönetimi ise Sistem Konsolu altındadır.)
2. Buton / aksiyon gating
Sayfa içindeki her yazma/silme/kontrol butonu, ilgili izne bağlı olarak koşullu çizilir. Sayfayı açan kullanıcının o izni yoksa buton DOM'a hiç eklenmez — yani "pasif/gri buton" değil, hiç yok. Aşağıda kod-doğrulanmış örnekler:
| Sayfa | Buton / aksiyon | Gerekli izin | Viewer'da durum |
|---|---|---|---|
Cihazlar (/devices) | Cihaz oluştur / düzenle | write:device | Gizli |
| Cihazlar | Cihaz sil | delete:device | Gizli |
| Cihazlar | Gateway oluştur / düzenle | write:gateway | Gizli |
| Cihazlar | Gateway sil | delete:gateway | Gizli |
Alarmlar (/alarms) | Alarm kuralı oluştur / düzenle ("Yeni Alarm Kuralı") | write:alarm | Gizli |
Mahsuplaşma (/mahsuplasma) | "Grup kurulumunu başlat" / sihirbaz | manage:netting | Gizli |
İki katmanlı örnek (Cihazlar): Viewer, sol menüde "Cihazlar" girişini görür (çünkü read:device iznine sahip) ve cihaz listesini/detayını okuyabilir; ancak sayfadaki "Yeni Cihaz", "Düzenle" ve "Sil" butonları çizilmez (bunlar write:device / delete:device ister; aynı sayfadaki gateway butonları da write:gateway / delete:gateway ile korunur). Böylece aynı sayfada okuma serbest, değiştirme kapalı olur.
Eski firma düzeyi firmware yönetim sayfası (/admin/firmware) ve toplu OTA sayfası
(/admin/batch-ota) tenant arayüzünden tamamen kaldırıldı; her ikisi de
/console/firmwaree yönlendirir. Firmware yükleme / yayınlama / kullanımdan kaldırma
ve tekil/toplu OTA, rollback, takılan OTA temizliği artık yalnız süper yönetici
tarafından Sistem Konsolu → Firmware · OTA altında yapılır. Bu ekranın koruması
buton bazında değil, route seviyesinde süper yönetici kapısıdır: süper yönetici
olmayan hiç kimse ne menüyü ne de uçları görür (yetkisiz istek 403 SUPERUSER_REQUIRED
alır). Firmware kaldırmak yerine yine "Deprecate" (kullanımdan kaldır) işlemi
yapılır. Kullanıcı akışı için Sistem Konsolu — Firmware · OTA.
3. Ayarlar sekme / kart gating
Ayarlar menüsü herkese açıktır, fakat içindeki her sekme ve kart kendi iznini kontrol eder:
- Kullanıcılar sekmesi — yalnız
read:userizni olanlara sekme başlığı olarak görünür. İçeride kullanıcı eklemewrite:user, silmedelete:userister. Viewer bu izinlere sahip olmadığından sekmeyi hiç görmez; süper yönetici veya admin görür. - Marka / Genel Ayarlar kartı — kart
read:tenant_settingsile görünür; "Kaydet" butonu iseupdate:tenant_settingsizni yoksa devre dışı kalır (kart görünür ama değişiklik uygulanamaz).
Bu, "menüyü herkese aç, ayrıntıyı izinle kısıtla" desenidir: kullanıcı Ayarlar'a girer, yalnız yetkili olduğu sekmeleri/kartları görür.
4. Sayfa düzeyi gating (salt-okuma engeli)
Bazı sayfalar, okuma izni bile yoksa boş bir bilgilendirme kartı gösterir ve gereksiz veri isteği (dolayısıyla 403) yapmaz. Örneğin Mahsuplaşma panosu, read:netting izni olmayan kullanıcıya Mahsuplaşma modülü için "read:netting" yetkisi gerekir. Yöneticinizle iletişime geçin. mesajını içeren bir kart (NoReadPermissionCard) gösterir; alttaki veri sorguları yalnızca izin varsa (enabled: canRead) çalışır. Böylece:
- İzni olan kullanıcı → veriyi görür + yetkisi ölçüsünde aksiyon butonlarını görür.
- Okuma izni olmayan kullanıcı → boş, açıklayıcı kart görür (ekran çökmez, ham hata görünmez).
Benzer şekilde Kullanıcılar sekmesi, read:user izni yoksa "Bu sayfayı görüntülemek için read:user izniniz olmalı. Yöneticinizden yetki talep edin." mesajını gösterir.
Viewer (salt-okuma) rolü — tam davranış özeti
Viewer rolünün arayüzde ne gördüğünü tek bakışta özetleyelim:
- Sol menüde görünür: Dashboard, Bölgeler, Gateway'ler, Cihazlar, OSOS/DSO, Ölçümler, Alarmlar, Raporlar, Mahsuplaşma, Piyasa Fiyatları, SLD, LOTO, Ayarlar.
- Sol menüde GİZLİ: Şarj İstasyonları, Ödemeler, WhatsApp Bridge, Sistem Konsolu. (Firmware ve Toplu OTA menüleri artık hiçbir firma rolünde yoktur — süper yönetici konsoluna taşındı.)
- Butonlar: Hiçbir "oluştur / düzenle / sil / kontrol / senkron / mahsuplaşma yönet" butonu görünmez. Yalnız listeleme, detay ve (Raporlar'da) dışa aktarma kalır.
- Ayarlar: Menü açılır ama Kullanıcılar sekmesi görünmez; salt-okuma kartlarında "Kaydet" devre dışıdır.
Bir kullanıcı bir menüyü/butonu göremiyorsa, çözüm arayüzde değil rol atamasındadır. Rol ataması Ayarlar → Kullanıcılar sekmesinde yapılır (bu sekme read:user, kullanıcı düzenleme write:user izni ister); firmalar-arası (cross-tenant) kullanıcı yönetimi ise süper yönetici için Sistem Konsolu → Kullanıcılar altındadır. Yöneticiniz kullanıcıya daha yetkili bir rol (ör. Viewer → Operator) atadığında, kullanıcı çıkış-giriş yaptıktan (veya oturumu yenilendikten) sonra yeni menü ve butonlar otomatik belirir. Roller ve izinler için bu sayfadaki İzin Matrisi bölümüne bakın.