İzinlere duyarlı gezinme menüleri açıklık sağlar, ancak güvenlik arka uçta kalmalıdır. Roller, politikalar ve güvenli UI gizleme için basit desenleri görün.

İ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:
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:
Ö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 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:
“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.
İ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:
İ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:
noun.verb (veya resource.action) kullanınÖ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.
İ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.
canEditCustomers, canDeleteCustomers, canExport gibi boolean'lar veya kompakt izin stringleri listesi gönderin. Minimal tutun.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.
İ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.
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.
Öğ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:
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.
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:
Can(user, "invoice.delete", invoice)).Frontend ve loglarınız için yardımcı olacak status kodlarını kullanın:
401 Unauthorized.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.
Ç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.
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.
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:
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:
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:
leads.delete izni var mı?lead.owner_id == user.id 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ı.
İ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:
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.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.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.
İ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:
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ı.
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:
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.
İzinlere duyarlı menüler büyük ölçüde açıklık sağlar, güvenlik sağlamaz. Kullanıcılara gerçekten neler yapabileceklerini gösterir, çıkmaz tıklamaları azaltır ve “bunu neden görüyorum?” destek sorularını azaltır.
Güvenlik yine de sunucu tarafında sağlanmalıdır; çünkü biri derin bağlantılar, eski yer imleri veya doğrudan API çağrılarıyla UI'da ne gösterilirse gösterilsin denemeler yapabilir.
Bir rol için özellik keşfedilmeyecekse, öğeyi gizleyin.
Kullanıcının erişimi olabilir ama şu an bağlam eksikse, öğeyi devre dışı bırakın (örneğin, hiçbir kayıt seçilmemişse veya veri yükleniyorsa). Devre dışı bıraktığınızda kısa bir açıklama ekleyin, böylece bozuk gibi görünmesin.
Çünkü görünürlük yetkilendirme değildir. Bir kullanıcı URL yapıştırabilir, yer imindeki bir yönetici ekranını yeniden kullanabilir veya UI dışından API çağrısı yapabilir.
UI'ı rehber olarak görün. Her hassas istekte nihai kararı veren taraf sunucu olsun.
Sunucunuz, girişten sonra veya oturum yenilemede küçük bir “yetenekler” yanıtı döndürmelidir; bu yanıt sunucu tarafı izin kontrollerine dayanır. UI, menüleri ve düğmeleri bu bilgilere göre render eder.
Tarayıcıdan gelen isAdmin gibi istemci tarafı bayraklara güvenmeyin; izinleri sunucuda kimlik doğrulamasıyla hesaplayın.
Önce eylemleri envantere alın, sayfaları değil. Her özellik için read, create, update, delete, export, invite, fatura değişikliği gibi ayrı işleri belirleyin.
Sonra her eylemi backend handler'ında (veya middleware/wrapper'da) işlemeden önce yetkilendirin. Menüyü aynı izin adlarına bağlayın ki UI ve API uyumlu kalsın.
Pratik bir varsayılan: roller kovadır, izinler gerçek kaynaktır. İzinleri küçük ve eylem tabanlı tutun (ör. invoice.create) ve bunları rollere atayın.
Roller bölünmeye başlayıp koşulları kodlamak için kullanılıyorsa (ör. bölge veya sahiplik), bu koşulları politikalarla ifade edin, yeni roller yaratmayın.
“Kendi kaydını düzenleyebilir” veya “belirli bir limitin altındaki faturaları onaylayabilir” gibi koşullu kurallar için politikalar kullanın. Bu, izin listesini sabit tutarken gerçek dünya kısıtlarını ifade etmenizi sağlar.
Backend, politikayı resource bağlamı (sahip ID veya org ID gibi) kullanarak değerlendirmeli, UI varsayımlarına dayanmamalıdır.
Her zaman değil. Ancak hassas veri döndüren veya normal filtrelemeyi atlayan okumalar da korunmalıdır; örneğin exportlar, denetim logları, maaş verileri veya admin kullanıcı listeleri.
İyi bir kural: tüm yazma işlemleri mutlaka kontrol edilmeli; hassas okumalar da kontrol edilmeli.
Toplu uç noktalar kolayca gözden kaçırılır çünkü tek istekte birçok kaydı veya alanı değiştirebilirler. UI'da engellenmiş bir kullanıcı /bulk-update gibi bir uç noktayı doğrudan çağırabilir.
Toplu eylem için izinleri kontrol edin ve ayrıca hangi alanların rol için değiştirilebileceğini doğrulayın; aksi halde gizli alanlar kazara düzenlenebilir.
İzinlerin oturum sırasında değişebileceğini varsayın. API 401 veya 403 döndüğünde UI bunu normal bir durum olarak ele almalı: yetenekleri yenilemeli, menüyü güncellemeli ve net bir mesaj göstermeli.
Ayrıca menü görünürlüğünü paylaşılan cihazlarda hesaplar arası sızıntı yaratmayacak şekilde saklayın; cache'lerseniz kullanıcı kimliğine göre anahtarlayın veya hiç saklamayın.