Allow ve Deny

Ek bilgi bölümü 8.5

Tercüme Yüzdesi

Bu bölümde:

  • Allow ve Deny geriçağırımlarını öğreneceğiz.
  • Geriçağırımların hangi sırada uygulandığını anlayacağız.
  • Meteor'un güvenlik sistemi veritabanında yaptığımız her değişiklikte yeni bir Method tanıtma yerine yapılan değişiklikleri kontrol etmemize izin verir.

    Daha önce post bilgisine ekstra özellikler eklediğimizden ve URL'ın daha önce eklenip eklenmediğine baktığımız için Method eklemek mantıklı bir adımdı.

    Fakat, post'u güncellerken ve silerken yeni bir Method eklemeye ihtiyac duymadık. Bunun için sadece kullanıcının silme ve güncelleme hakkının olup olmadıgına baktık, ve bunu allow ve deny kullanarak kolaylıkla yaptık.

    Bu geriçağırımları kullanmak veritabanında yaptığımız değişiklikleri, ve güncellemeleri daha net bir şekilde ifade etmemize yardımcı olur. Özellikle bunları tanımlarken kullanıcı sistemini de kullanabilmemiz bizim için ekstra bir avantajdır.

    Çoklu geriçağırım

    İstediğimiz kadar allow geriçağırımı tanıtabiliriz. Veritabanına değişikliğin kaydedilmesi için bunlardan en az birinin true dönmesi bizim için yeterli. Eğer Posts.insert kodu çağırıldığında (yaptığımız app'ın sayfasından ya da tarayıcının konsolundan direk olarak), server tarafındaki insert için tanıtılan allow kontrollerden herhangi biri true dönene kadar bütün kontroller denenir. Eğer bulunamazsa, veritabanına ekleme yapılmaz ve server geriye 403 hatası döner.

    Aynı şekilde birden fazla deny geriçağırımı ekleyebiliriz. Eğer bunlardan herhangi biri true dönerse değişiklik durdurulur ve geriye 403 hata kodlu sayfa dönülür. Bundan ötürü eğer başarılı bir insert yapılması için kodumuzun bütün deny insert geriçağırımlarından sonra allow insert geriçağırımlarının bir veya birden fazlasından geçmesi gerekir.

    Note: n/e stands for Not Executed
    Note: n/e stands for Not Executed

    Meteor deny geriçağırımlarından başlayarak allow listesine gider ve herhangi biri true dönene kadar tek tek geriçağırımları dener.

    Uygulamalı bir örnek olarak iki tane allow() geriçağırımı olduğunu düşünelim: birinin postun giriş yapan kullanıcıya ait olup olmadığını, diğerinin de kullanıcının admin olup olmadığını kontrol ediyor olduğunu düşünelim. Eğer giriş yapan kullanıcı admin ise, herhangi posta değişiklik yapabilecektir, çünkü bu iki geriçağırımdan biri true dönecektir.

    Gecikme Telafisi

    Unutmayın ki veritabanında değişiklik yapan Methodlar (örneğin .update()) gecikme telafisinden geçer. Mesela kullanıcıya ait olmayan post tarayıcı konsolundan silindiğinde bu döküman lokal kolleksiyondan silindiği için post'un geçici olarak yok olduğunu görürüz. Fakat kısa bir süre sonra server tarafından dökümanın silinmediğini öğrenince bunun tekrardan geri geldiğini görürüz.

    Genelde konsoldan yapılan değişiklikler problem değildir (ne de olsa kullanıcıların büyük bir kısmı tarayıcı konsolundan değişiklik yapmayacaklardır). Fakat bu tür değişikler kullanıcı arayüzünden kaynaklanmamalı. Örneğin, eğer kullanıcıya ait olmayan dökümanların silinmemesini istiyorsan kullanıcıya sil tuşunu göstermemen gerekir.

    Dökümanlara ait gerekli izinleri (örneğin /lib klasörü altında kullanıcıların dökümanı silip silemeyeceğini belirten canDeletePost(user, post) fonksiyonu tanıtıp) kullanıcı ve server'ın ortak kullanacağı şekilde kodlayabilirsin.

    Server Tarafından İzin

    Veritabanına yapılan değişikleri kontrolden geçiren bu izin sisteminin sadece kullanıcı tarafından engellendiğini unutmamak gerekir. Server tarafında yapılan bütün değişiklikler herhangi bir engele takılmadan kabul edilir.

    Eğer örnek olarak server tarafında tanıtılan bir deletePost Meteor Method'u kullanıcı tarafından çağırılabilirse, herhangi bir kullanıcı post dökümanlarını silebilecektir. Bu nedenle, server tarafından yapılan değişikliklerde öncelikle gerekli izinleri gözden geçirmek gerekir.