08s-allow-and-deny.md.erb

---
title: Allow ve Deny
slug: allow-and-deny
date: 0008/01/02
number: 8.5
sidebar: true
contents: Allow ve Deny geriçağırımlarını öğreneceğiz.|Geriçağırımların hangi sırada uygulandığını anlayacağız.
paragraphs: 16
---
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.

<%= diagram "allow_deny", "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 `post`un 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 `post`a 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.