Erişimi zorunlu kılan, izinlere duyarlı gezinme menüleri

İzinlere duyarlı menülerin aslında hangi problemi çözdüğü

İnsanlar “butonu gizle” dediğinde genellikle iki şeyden birini kasteder: özelliği kullanamayanlar için kalabalığı azaltmak ya da kötüye kullanımı engellemek. Ön yüzde yalnızca ilk hedef gerçekçidir.

İzinlere duyarlı gezinme menüleri esasen bir UX aracıdır. Kullanıcının uygulamayı açtığında hemen neler yapabileceğini görmesine yardımcı olur, her tıklamada “Erişim reddedildi” sayfalarıyla karşılaşmayı azaltır. Ayrıca “Faturaları nereden onaylarım?” veya “Bu sayfa neden hata veriyor?” gibi kafa karışıklıklarını önleyerek destek yükünü azaltır.

UI gizleme güvenlik değildir. Açıklıktır.

Meraklı bir iş arkadaşı bile şunları yapabilir:

• URL'yi biliyorsa gizli bir sayfaya doğrudan derin bağlantı yazmak
• Eski bir yer imini açmak ve bir admin ekranına gitmek
• Bir betik veya araçla API'nizi doğrudan çağırmak
• Tarayıcıdan istekleri değiştirip farklı ID'ler denemek

Dolayısıyla izinlere duyarlı menülerin gerçek çözümü dürüst rehberliktir. Arayüzü kullanıcının işi, rolü ve bağlamıyla hizalı tutar ve bir şey mevcut olmadığında bunun nedenini anlaşılır kılar.

İyi bir hedef durum şöyle görünür:

• Kullanıcılar çoğunlukla kendilerine anlamlı eylemleri görür ve sürpriz hatalar nadir olur.
• Geliştiricilerin dağınık kontroller yerine tek bir paylaşılmış doğruluk kaynağı olur.
• Ürün değişiklikleri daha güvenli olur çünkü yeni bir menü öğesi eklediğinizde hangi iznin gerektiğine karar vermeniz gerekir.
• Güvenlik önemli yerde uygulanır: arka uç her zaman yasaklanmış eylemleri reddeder, UI yanlışlıkla onları gösterse bile.

Örnek: küçük bir CRM'de Sales Rolü Leads ve Tasks görmeli ama User Management görmemeli. Yine de kullanıcı user management URL'sini yapıştırırsa sayfa kapalı şekilde başarısız olmalı ve sunucu kullanıcıları listeleme veya roller değiştirme girişimlerini engellemelidir.

Görünürlük yetkilendirme değildir

Görünürlük arayüzün neyi göstermeyi seçtiğidir. Yetkilendirme ise bir istek sunucuya ulaştığında sistemin aslında neye izin vereceğidir.

İzinlere duyarlı menüler kafa karışıklığını azaltır. Birinin asla Billing veya Admin görmesine izin verilmeyecekse o öğeleri gizlemek uygulamayı temiz tutar ve destek taleplerini azaltır. Ancak bir düğmeyi gizlemek kilit değildir. İnsanlar yine de geliştirici araçları, eski bir yer imi veya kopyalanmış bir istekle alttaki uç noktayı deneyebilir.

Pratik bir kural: hangi deneyimi istediğinize karar verin, sonra kuralı UI ne yaparsa yapsın arka uçta zorunlu kılın.

Bir eylemi sunarken üç desen çoğu durumu kapsar:

• Gizle: Özellik çoğu rol için keşfedilmez olmalıysa (ör. sadece dahili araçlar).
• Devre dışı bırak: Özellik var ama kullanıcı şu an yapamaz (ör. plan yükseltmesi bekleniyor, kayıt seçilmemiş, veri yükleniyor).
• Açıklamasıyla göster: Kullanıcıların neden devam edemeyeceğini anlaması gerekiyorsa (“Faturaları görüntüleyebilirsiniz, ancak ödeme yöntemlerini yalnızca Ownerlar düzenleyebilir”).

“Görüntüleyebilir ama düzenleyemez” yaygındır ve açıkça tasarlamaya değer. Bunu okumak ve değiştirmek için ayrı izinler olarak ele alın. Menüde müşteri detaylarını okuma izni olan herkese gösterebilir, ancak Düzenle müşteri yalnızca yazma izni olanlara gösterilebilir. Sayfada alanları salt okunur render edin ve düzenleme kontrollerini engelleyin, sayfanın yine de yüklenmesine izin verin.

En önemlisi: son kararı arka uç verir. UI her admin eylemini gizlese bile, sunucu her hassas istekte izinleri kontrol etmeli ve birisi denediğinde net bir “izin yok” yanıtı döndürmelidir.

Sürdürülebilir bir izin modeli seçin

İzinlere duyarlı menüleri en hızlı şekilde hayata geçirmek, ekibinizin bir cümlede açıklayabileceği bir modelle başlamaktır. Açıklayamıyorsanız, doğru tutamazsınız.

Rolleri gruplayıcı olarak kullanın, anlam için değil. Admin ve Support faydalı kovalar olabilir. Ancak roller çoğalmaya başladığında (Admin-West-Coast-ReadOnly gibi), UI bir labirente döner ve arka uç tahmin işi olur.

Birinin ne yapabileceğini en iyi tanımlayan kaynak olarak izinleri tercih edin. İzinleri küçük ve eylem tabanlı tutun, ör. invoice.create veya customer.export. Bu, yeni özelliklerin genellikle yeni eylemler eklemesiyle daha iyi ölçeklenir; yeni iş unvanları eklemekle değil.

Sonra bağlam için politikalar ekleyin. “Sadece kendi kaydını düzenleyebilir” veya “$5,000 altındaki faturaları onaylayabilir” gibi durumları burada ele alırsınız. Politikalar, koşul farkından dolayı onlarca neredeyse aynı izni oluşturmanızı engeller.

Sürdürülebilir bir katmanlama şöyle görünür:

• Roller izinleri gruplar (iş fonksiyonu)
• İzinler eylemleri tanımlar (ne)
• Politikalar bağlam ekler (ne zaman, hangi kayıtlar)

İsimlendirme insanların beklediğinden daha önemlidir. UI Export Customers derken API download_all_clients_v2 kullanıyorsa, sonunda yanlış şeyi gizler veya doğru şeyi engellersiniz. İsimleri insan odaklı, tutarlı ve frontend ile backend arasında paylaşılan şekilde tutun:

• Tutarlı olarak noun.verb (veya resource.action) kullanın
• UI etiketlerini izin niyetine göre eşleştirin, dahili kod isimlerine göre değil
• Özellikleri yeniden adlandırırken eski izin isimlerini çalışır halde tutun

Örnek: CRM'de Sales rolü lead.create ve lead.update içerebilir, ancak bir politika güncellemeleri yalnızca kullanıcının sahip olduğu lead'lere sınırlar. Bu, menünüzü net tutarken arka ucun katı kalmasını sağlar.

Adım adım: roller ve izinleri uçtan uca uygulayın

İzinlere duyarlı menüler hoş hissettirir çünkü karmaşıklığı azaltır ve kazara tıklamaları engeller. Ancak arka uç kontrolü olduğunda yardımcı olurlar. UI'ı bir ipucu, sunucuyu yargıç olarak düşünün.

Korumak istediklerinizi yazmaya başlayın. Sayfalar değil, eylemler. Müşteri listesini görüntüleme, müşteri dışa aktarma ve müşteri silme farklıdır. Bu, güvenlik tiyatrosuna dönüşmeyen izinlere duyarlı gezinme menülerinin omurgasıdır.

Pratik uçtan uca reçete

1. UI ve API'deki eylemleri envantere alın. Her özellik için somut işlemleri listeleyin: read, create, update, delete, export, invite, change billing, run admin reports.
2. İzinleri sunucuda gerçek kaynak olarak tanımlayın. Rol-izin eşlemesini veritabanında (veya konfigürasyonda) saklayın ve her API handler'ının “bu kullanıcı X iznine Y kaynak üzerinde sahip mi?” diye sormasını sağlayın.
3. UI için küçük bir capabilities payload döndürün. Giriş sonrası (veya oturum yenilemede) canEditCustomers, canDeleteCustomers, canExport gibi boolean'lar veya kompakt izin stringleri listesi gönderin. Minimal tutun.
4. Her yazma isteğinde ve hassas okumalarda kontrolleri zorlayın. Tüm mutasyonlar izin kontrolü yapmalı. Bazı okumalar da yapmalı (ör. maaşlar, denetim logları, exportlar veya normal filtrelemeyi atlayan uç noktalar).
5. Birkaç role odaklı test ekleyin. 2-3 kilit rol seçin ve en yüksek riskli eylemleri test edin. Örnek: Sales anlaşma oluşturabilir ama müşteri dışa aktaramaz; Admin kullanıcı davet edebilir.

Küçük ama önemli bir kural: istemcinin gönderdiği role veya izin bayraklarına asla güvenmeyin. UI yeteneklere göre düğmeleri gizleyebilir, ancak API yetkisiz istekleri yine reddetmelidir.

Ön yüzde dürüst kalan desenler

İzinlere duyarlı menüler insanlara ne yapabileceklerini bulmada yardımcı olmalı, güvenlikmiş gibi davranmamalıdır. Ön yüz rehber bariyeridir. Arka uç kilittir.

Menüyü tek bir doğruluk kaynağından oluşturun

Her düğmenin etrafına izin kontrolleri serpiştirmek yerine, her öğe için gerekli izni içeren bir konfigürasyondan gezinimi tanımlayın ve bundan render edin. Bu kuralları okunabilir tutar ve UI'nın garip köşelerinde unutulan kontrolleri önler.

Basit bir desen şöyle görünür:

const menu = [
  { label: "Contacts", path: "/contacts", requires: "contacts.read" },
  { label: "Export", action: "contacts.export", requires: "contacts.export" },
  { label: "Admin", path: "/admin", requires: "admin.access" },
];

const visibleMenu = menu.filter(item => userPerms.includes(item.requires));

Bütün bölümleri (ör. Admin) komple gizlemeyi, her admin sayfası linkine ayrı ayrı kontroller serpmekten tercih edin. Bu daha az yerde hata yapma olanağı sağlar.

Dürüst durumlar: gizle vs devre dışı bırak

Öğeleri, kullanıcıya asla izin verilmeyecekse gizleyin. Kullanıcının izni var ama bağlam eksikse devre dışı bırakın.

Örnek: Kişiyi silme, bir kişi seçilene kadar devre dışı olmalı. Aynı izin, sadece yeterli bağlam yok. Devre dışıyken kontrolün yakınında kısa bir “neden” bilgisi ekleyin (tooltip, yardımcı metin veya inline not): Bir kişi seçin ki silebilesiniz.

Dayanıklı bir kural seti:

• Kullanıcı izin sahibi değilse gizle.
• Kullanıcı izin sahibiyse ama seçim yoksa, form geçersizse veya veri yükleniyorsa devre dışı bırak.
• İzinler için local storage'ı asla kaynak olarak kabul etmeyin. O yalnızca bir önbellektir.
• Giriş, rol değişimi veya hesap değişimi sonrası izinleri tekrar kontrol edin.

Aşılamaz arka uç zorlaması

Menü öğelerini gizlemek insanların odaklanmasına yardımcı olur, ama hiçbir şeyi korumaz. Talepler yeniden oynatılabilir, düzenlenebilir veya UI dışında tetiklenebilir, bu yüzden arka uç nihai hakem olmalıdır.

İyi bir kural: veriyi değiştiren her eylem için isteğin geçtiği yolun bir yerinde tek bir yetkilendirme kontrolü olsun. Bu middleware, handler sarmalayıcı veya her uç noktada çağrılan küçük bir politika katmanı olabilir. Bir yaklaşım seçin ve ona bağlı kalın, yoksa yolları kaçırırsınız.

Kontrolü istek yoluna yerleştirin

Yetkilendirmeyi girdi doğrulamadan ayrı tutun. Önce “bu kullanıcı bunu yapmaya izinli mi?” kararını verin, sonra payload'u doğrulayın. Önce doğrularsanız, var olmaması gereken yapıların (örn. kayıt IDleri) sızmasına neden olabilirsiniz.

Ölçeklenen bir desen:

• Çağıranı kimlik doğrulayın ve net bir kimlik oluşturun (user id, org id, roller, izinler).
• Yetkilendirme için ihtiyaç duyduğunuz kaynak bağlamını yükleyin (çoğunlukla owner id veya org id).
• Tek bir politika fonksiyonu çağırın (örneğin: Can(user, "invoice.delete", invoice)).
• Reddedildiyse hemen durun ve doğru statüyü döndürün.
• Sadece sonra payload'u doğrulayın ve iş mantığını çalıştırın.

Açık, tutarlı yanıtlar döndürün

Frontend ve loglarınız için yardımcı olacak status kodlarını kullanın:

• Giriş yapılmamışsa 401 Unauthorized.
• Giriş yapılmış ama yetkisi yoksa 403 Forbidden.

Kaynağın varlığını gizlemek için 404 Not Found kullanımı dikkat gerektirir. Yararlı olabilir, ama karışık kullanırsanız hata ayıklama zorlaşır. Kaynak tipi başına tutarlı bir kural seçin.

Aynı yetkilendirme, eylem butonundan, mobil uygulamadan, bir betikten veya doğrudan API çağrısından gelmiş olsun çalışmalı.

Son olarak, reddedilen girişimleri hata ayıklama ve denetimler için loglayın ama logları güvende tutun. Kim, hangi eylem ve hangi üst düzey kaynak tipi kaydedilsin; hassas alanlar, tam payload veya sırlar kaydedilmesin.

Tasarımı yapan ya da bozan uç durumlar

Çoğu izin hatası menünüzün hiç beklemediği yollar kullanıcılar tarafından kullanıldığında ortaya çıkar. Bu yüzden izinlere duyarlı menüler faydalıdır, ama bunları atlayan yolları da tasarlamanız gerekir.

Derin bağlantılar ve “gizli” ekranlar

Menü bir rol için Billing'i gizliyorsa kullanıcı yine de kaydedilmiş bir URL yapıştırabilir veya tarayıcı geçmişinden açabilir. Her sayfa yüklemesini taze bir istek gibi ele alın: kullanıcının mevcut izinlerini alın ve ekran korunan veriyi yüklemeyi reddetsin. Dostça bir “Erişim yok” mesajı uygundur, ama gerçek koruma arka uç hiçbir şey döndürmemesidir.

Doğrudan API çağrıları ve toplu uç noktalar

Herkes API'nizi devtools, bir betik veya başka bir istemciyle çağırabilir. Bu yüzden tüm uç noktalarda izin kontrolü yapın, sadece admin ekranlarında değil. Kaçırılması kolay risk toplu eylemlerdedir: tek bir /items/bulk-update yetkisi olmayan bir kullanıcıya, UI'da görmediği alanları değiştirme olanağı verebilir.

Roller oturum ortasında da değişebilir. Bir admin bir izni kaldırdığında kullanıcı hala eski bir token veya önbelleklenmiş menü durumuna sahip olabilir. Kısa ömürlü tokenlar ya da sunucu tarafı izin araması kullanın ve 401/403 yanıtlarını alıp izinleri yenileyerek UI'yı güncelleyin.

Paylaşılan cihazlar başka bir tuzak yaratır: önbelleğe alınmış menü durumu hesaplar arasında sızıntı yapabilir. Menü görünürlüğünü kullanıcı ID'sine göre anahtarlayın veya hiç saklamayın.

Dağıtımdan önce çalıştırılmaya değer beş test:

• Sınırlı bir rol ile gizli bir sayfaya derin bağlantı açın
• Geliştirici araçlarından kopyalanmış bir istekle korunan bir API'yi çağırın
• Kullanıcının rolünü aktifken değiştirin, sonra eylemleri yeniden deneyin
• Çıkış yapıp başka bir kullanıcıyla tekrar giriş yapın ve menünün sıfırlandığını doğrulayın
• Karışık izinli ve izinsiz alanlar içeren toplu uç noktaları deneyin

Örnek senaryo: gerçek uygulama ile basit bir CRM menüsü

Diyelim iç kullanım amaçlı bir CRM var ve üç rol: Sales, Support ve Admin. Herkes giriş yapar ve uygulama solda bir menü gösterir, ama menü sadece bir kolaylıktır. Gerçek güvenlik sunucunun izin verdiği şeydir.

Okunması kolay bir izin seti şöyle olsun:

• Leads: view, create, edit, delete, export
• Tickets: view, create, edit, assign
• Billing: view, edit
• Users: view, manage

UI önce sunucudan kullanıcının izinli eylemlerini (genellikle izin stringleri listesi olarak) artı kullanıcı id ve ekip gibi temel bağlamı ister. Menü bundan oluşturulur. Eğer billing.view yoksa Billing görünmez. Eğer leads.export varsa Leads ekranında Export düğmesini görürsünüz. Sadece kendi lead'lerini düzenleyebiliyorsanız Edit düğmesi yine görülebilir, ama lead sizin değilse devre dışı olmalı veya net bir mesaj göstermelidir.

Şimdi önemli kısım: her eylem uç noktası aynı kuralları uygular.

Örnek: Sales lead oluşturabilir ve sahip olduğu lead'leri düzenleyebilir. Support ticket'ları görüntüleyip atayabilir ama billing ile uğraşamaz. Admin kullanıcıları ve billing'i yönetebilir.

Birisi bir lead'i silmeye çalıştığında arka uç şöyle kontrol eder:

1. Kullanıcının leads.delete izni var mı?
2. Eğer kural sadece kendi kaydıysa, lead.owner_id == user.id mi?
3. Eğer lead kilitliyse (ör. zaten faturalandırılmışsa), silme yalnızca Admin için engellenmiş mi?

Support kullanıcısı silme uç noktasını elle çağırsa bile forbidden yanıtı alır. Gizli menü öğesi koruma olmadı. Arka uç kararı korumaydı.

Yaygın hatalar ve tuzaklar

İzinlere duyarlı menülerdeki en büyük tuzak menü düzgün göründüğünde işi bitirdiğinizi sanmaktır. Butonları gizlemek kafa karışıklığını azaltır ama riski azaltmaz.

En sık görülen hatalar:

• “Görünmüyor” = “mümkün değil” sanmak. Biri yine de API'yi doğrudan çağırabilir, eski bir URL kullanabilir veya devtools ile eylemi tetikleyebilir.
• İzinlerin sadece UI'da kontrol edilmesi. Eğer frontend kim silinebileceğine karar veriyorsa işi kaybettiniz. Arka uç her korunan eylem için nihai hakem olmalıdır.
• Her şey için tek bir isAdmin bayrağı. Hızlı gelir, sonra yayılır. Kısa süre sonra istisnalar çoğalır ve kimse erişim kurallarını açıklayamaz.
• İstemcinin rolünü size söylemesine güvenmek. Tarayıcıdan gelen role, isAdmin veya permissions verilerine asla inanmayın. Kimliği kendi oturumunuz veya token'ınızdan türetin, sonra roller ve izinlere sunucu tarafında bakın.
• Okuma izinlerini unutmak. Ekipler yazmalara odaklanır, ancak veri sızıntıları genellikle okumalardan gelir. Müşteri listeleri, faturalar, CSV dışa aktarma ve arama genellikle kontrol gerektirir.

Somut bir örnek: Export leads menü öğesini manager olmayanlar için gizlediniz. Eğer export uç noktası da izin kontrolü yapmıyorsa, herhangi bir kullanıcı isteği tahmin ederek (veya bir meslektaşından kopyalayarak) dosyayı yine indirebilir.

Yayına almadan önce hızlı kontrol listesi

İzinlere duyarlı menüleri yayınlamadan önce, kullanıcıların gerçekten ne yapabildiğine odaklanan son bir tur yapın, sadece ne gördüklerine değil.

Uygulamanızı her ana rol gibi dolaşın ve aynı eylem setini deneyin. Bunu UI içinde ve uç noktayı doğrudan çağırarak (veya tarayıcı geliştirici araçlarını kullanarak) yapın, sunucunun gerçek kaynak olduğunu doğrulamak için.

Kontrol listesi:

• Her korunan eylem için yürütme noktasında sunucu tarafı bir yetkilendirme kontrolü olduğundan emin olun (sadece menü oluştururken değil).
• UI'nın eylemleri sunucudan sağlanan yeteneklerden (ör. oturumdaki can-list veya permissions uç noktası) oluşturduğundan emin olun; rol isimlerinden tahmin etmeyin.
• UI'nın yasaklanmış yanıtları normal durummuş gibi ele almasını doğrulayın: net bir mesaj gösterin, sayfayı stabil tutun ve kullanıcıyı kırık bir durumda bırakmayın.
• Rol ve izin değişikliklerini test edin. Bir admin erişimi güncellediğinde etkisi hızlı ve öngörülebilir olmalı (token yenileme, oturum geçersiz kılma veya izin versiyonlaması).
• Para, dışa aktarma, silme ve admin ayarlarını etkileyen roller ve eylemleri kapsayan birkaç yüksek değerde test çalıştırın.

Boşlukları bulmanın pratik yolu: tehlikeli bir düğmü (kullanıcı sil, CSV dışa aktar, fatura değiştir) seçin ve baştan sona takip edin. Menü öğesi uygun olduğunda gizlenmeli, API yetkisiz çağrıları reddetmeli ve UI 403 aldığında düzgün toparlanmalı.

Sonraki adımlar: yavaşlamadan güvenle yayınlayın

Küçük başlayın. İlk günde mükemmel bir erişim matrisi olması gerekmez. En önemli birkaç eylemi seçin (view, create, edit, delete, export, manage users), bunları mevcut rollere eşleyin ve devam edin. Yeni bir özellik geldiğinde yalnızca getirdiği yeni eylemleri ekleyin.

Ekranları inşa etmeden önce eylemleri listeleyen kısa bir plan geçişi yapın. Invoices gibi bir menü öğesi birçok eylemi gizler: listeyi görüntüle, detayları görüntüle, oluştur, iade et, dışa aktar. Bunları önceden yazmak UI ve backend kurallarını netleştirir ve bütün bir sayfayı engelleyip riskli bir uç noktayı korumasız bırakma hatasını önler.

Erişim kurallarını yeniden düzenlerken bunu diğer riskli değişiklikler gibi ele alın: bir güvenlik ağı tutun. Snapshots davranışı önce ve sonra karşılaştırmanıza izin verir. Bir rol aniden ihtiyaç duyduğu erişimi kaybeder veya gereksiz erişim kazanırsa rollback, üretimde kullanıcılar engellenirken acil düzeltmeden daha hızlıdır.

Basit bir yayın rutini ekiplerin tahmin etmeden hızlı ilerlemesini sağlar:

• Özellik için eylemler listesi yazın ve her izin için isim verin.
• Önce backend kontrollerini ekleyin, sonra UI görünürlüğünü aynı izinlere bağlayın.
• Her riskli eylem için bir izinli rol ve bir reddedilmiş rol test edin.
• Reddedilen denemeleri (hassas veri olmadan) loglayın ki boşlukları görebilesiniz.
• Yayından önce snapshot alın ki hızlı geri alınabilesiniz.

Eğer sohbet tabanlı bir platformla geliştiriyorsanız, ör. Koder.ai (koder.ai), aynı yapı geçerlidir: izinleri ve politikaları bir kez tanımlayın, UI yetenekleri sunucudan okusun ve arka uç kontroller her handler'da isteğe bağlı olmamalıdır.