Garfield
YZF Admin
Araç parametrelerini çalıştırmadan önce doğrulamak için gelen girdiyi bir şemaya göre kontrol edin; zorunlu alanları, veri türlerini, izin verilen değerleri ve birbiriyle ilişkili koşulları kontrol edin, uygunsuz girdileri aracı çağırmadan reddedin. Yalnız doğrulamadan geçen parametreleri araca gönderin. Böylece eksik, hatalı biçimli veya yetkisiz istekler dış sisteme ulaşmadan durdurulur; ancak doğrulama, aracın gerçekten beklenen işi yapacağını tek başına kanıtlamaz.
Metni güvenli biçimde ayrıştırın; gerekli normalizasyonu alanın anlamını koruyarak yapın, ardından kullanılacak bu gösterimin şemasını, iş kurallarını ve yetkisini kontrol edin. Şema kontrolü gönderim yetkisini vermez; bütün kontroller geçmeden aracı çalıştırmayın. Örneğin bir e-posta gönderme aracına alıcı, konu ve ileti gövdesi gönderiyorsanız alıcının metin olması yetmez; boş olmaması ve beklenen e-posta biçimine uyması da gerekir.
Şema doğrulaması, verinin yapısını denetler: alan var mı, türü doğru mu, dizi beklenen biçimde mi? İş kuralı doğrulaması ise bu verinin gerçekten yapılabilir ve izin verilen bir işlem oluşturup oluşturmadığını inceler. İkisini tek kontrolde birleştirmemek, hatanın nerede oluştuğunu anlamayı kolaylaştırır.
Şema kullanıyorsanız aşağıdaki örnek, varsayımsal bir e-posta aracı için beklenen temel yapıyı gösterir. Bu, tek başına e-postanın gerçekten gönderileceğini veya kullanıcının gönderme yetkisi olduğunu doğrulamaz.
Örneğin aşağıdaki girdi yapısal olarak eksiktir:
Bu durumda
Hata yanıtı, akışın neden durduğunu ve düzeltilecek alanı açıkça belirtmelidir. Örneğin
Doğrulama çıktısında ham gizli değerleri, erişim belirteçlerini ve gereksiz kişisel verileri kaydetmeyin. Tanılama için ayrıntılı günlük tutuluyorsa iş tamamlandıktan sonra geçici çıktıları kaldırın veya maskeleyin. Birden fazla hata varsa mümkünse alan adı, hata türü ve beklenen koşulu ayrı ayrı döndürün; fakat bu hataları düzeltmeden aracı kısmen çalıştırmayın.
Başarılı doğrulama, parametrelerin tanımlanan biçime ve belirlediğiniz iş kurallarına uyduğunu gösterir. Ağ bağlantısının çalıştığını, dış servisin kullanılabilir olduğunu, kaydın hâlâ mevcut olduğunu veya işlemin kesin olarak tamamlandığını göstermez. Bu nedenle araç çağrısından sonra servis yanıtını, durum kodunu ve beklenen sonuç alanlarını da doğrulayın.
Bir parametre doğrulamada başarısız olursa aracı yeniden denemeden önce hatanın türünü ayırın: eksik veya yanlış biçimli veri istemcide düzeltilmelidir; yetki hatası kimlik ve erişim kapsamıyla kontrol edilmelidir; dış servisin reddettiği işlemde ise servis yanıtındaki hata kodu ve ilgili parametre birlikte incelenmelidir.
Doğrulama hangi sırayla yapılmalı?
Metni güvenli biçimde ayrıştırın; gerekli normalizasyonu alanın anlamını koruyarak yapın, ardından kullanılacak bu gösterimin şemasını, iş kurallarını ve yetkisini kontrol edin. Şema kontrolü gönderim yetkisini vermez; bütün kontroller geçmeden aracı çalıştırmayın. Örneğin bir e-posta gönderme aracına alıcı, konu ve ileti gövdesi gönderiyorsanız alıcının metin olması yetmez; boş olmaması ve beklenen e-posta biçimine uyması da gerekir.
- Gelen parametreyi güvenli biçimde ayrıştırın. Girdi JSON olarak geliyorsa önce geçerli JSON olup olmadığını kontrol edin. Ayrıştırma başarısızsa aracı çağırmadan güvenli bir hata döndürün. Gerekli boşluk veya gösterim normalizasyonunu doğrulama öncesinde, alanın kurallarına göre uygulayın; sözdizimi bozuksa bir alanın mutlaka belirlenebileceğini varsaymayın.
- Zorunlu alanları ve veri türlerini doğrulayın. Örneğin
toalanı metin,subjectalanı boş olmayan metin,bodyalanı ise metin olmalıdır. Eksik alanları varsayılan değerle doldurmak yerine, iş için zorunluysa isteği reddedin. - Değer sınırlarını kontrol edin. Sayısal bir
limitalanı kullanılıyorsa sıfırdan büyük ve makul bir üst sınır içinde olmasını sağlayın. Birformatalanı yalnızcaplainveyahtmlkabul ediyorsa listedeki değerler dışındakileri geçirmeyin. - Alanlar arasındaki iş kurallarını uygulayın.
send_atverilmişse gelecekte bir tarih olmasını,attachmentverilmişse dosya kimliğinin de bulunmasını isteyin. Tek tek alanlar geçerli olsa bile birlikte kullanımları geçersiz olabilir. - Yetki ve kapsam kontrolü yapın. Kullanıcının bu aracı çağırmaya ve istenen kayda erişmeye yetkisi olduğunu doğrulayın. Parametrenin biçimsel olarak doğru olması, kullanıcının o işlem için yetkili olduğunu kanıtlamaz.
- Doğrulanan çıktıyı koruyun. Yalnızca kontrollerden geçen alanları araca aktarın. Doğrulamadan sonra değerleri yeniden normalize etmeyin veya modelden yeniden üretmeyin; değişen girdi bütün ilgili kontrollerden yeniden geçmelidir.
- Aracı yalnız bütün kontroller başarılıysa çalıştırın. Araç sunucusu yetkiyi gerçek kullanıcı ve hedef kaynak için denetlemeli, yalnız doğrulanan girdiyi yürütmelidir. Şema, iş kuralı veya yetki hatasında yan etki oluşmadan durun; güvenli hata mesajına gizli değerleri eklemeyin.
- Çalıştırma sonucunu ayrıca kontrol edin. Araçtan başarılı yanıt gelmesi işlemin iş kuralına uygun tamamlandığını her zaman göstermez. Yanıtta beklenen kayıt kimliği, durum alanı veya işlem sonucu bulunuyor mu kontrol edin.
Şema doğrulaması ile iş kuralı doğrulamasını ayırın
Şema doğrulaması, verinin yapısını denetler: alan var mı, türü doğru mu, dizi beklenen biçimde mi? İş kuralı doğrulaması ise bu verinin gerçekten yapılabilir ve izin verilen bir işlem oluşturup oluşturmadığını inceler. İkisini tek kontrolde birleştirmemek, hatanın nerede oluştuğunu anlamayı kolaylaştırır.
| Kontrol katmanı | Örnek | Başarısızsa |
|---|---|---|
| Yapı | to alanı metin mi? | Aracı çağırmadan isteği reddedin. |
| Değer | E-posta biçimi geçerli mi? | Düzeltilmesi gereken alanı bildirin. |
| İş kuralı | Ek dosya varsa dosya kimliği var mı? | Aracı çağırmadan isteği reddedin. |
| Yetki | Kullanıcının bu kayda erişimi var mı? | Yetkisiz işlem olarak sonlandırın. |
JSON:
{
"type": "object",
"required": ["to", "subject", "body"],
"properties": {
"to": { "type": "string", "minLength": 1 },
"subject": { "type": "string", "minLength": 1 },
"body": { "type": "string", "minLength": 1 },
"format": { "enum": ["plain", "html"] }
},
"additionalProperties": false
}
Örneğin aşağıdaki girdi yapısal olarak eksiktir:
JSON:
{
"to": "[email protected]",
"body": "Rapor hazır."
}
Bu durumda
subject zorunlu olduğu için araç çalıştırılmaz. subject eklenip e-posta biçimi, yetki ve varsa gönderim sınırı da geçerliyse araç çağrısına geçilebilir. Buna karşılık to alanı dolu olsa bile geçersiz bir adres veya yetkisiz bir alıcı varsa doğrulama yine başarısız olmalıdır.Doğrulama hatası nasıl döndürülmeli?
Hata yanıtı, akışın neden durduğunu ve düzeltilecek alanı açıkça belirtmelidir. Örneğin
subject alanı zorunludur veya format yalnızca plain ya da html olabilir gibi bir mesaj uygulanabilir durumdadır. Buna karşılık yalnızca geçersiz istek demek, sorunu düzeltmek için yeterli bilgi vermez.Doğrulama çıktısında ham gizli değerleri, erişim belirteçlerini ve gereksiz kişisel verileri kaydetmeyin. Tanılama için ayrıntılı günlük tutuluyorsa iş tamamlandıktan sonra geçici çıktıları kaldırın veya maskeleyin. Birden fazla hata varsa mümkünse alan adı, hata türü ve beklenen koşulu ayrı ayrı döndürün; fakat bu hataları düzeltmeden aracı kısmen çalıştırmayın.
Doğrulama neyi kanıtlar, neyi kanıtlamaz?
Başarılı doğrulama, parametrelerin tanımlanan biçime ve belirlediğiniz iş kurallarına uyduğunu gösterir. Ağ bağlantısının çalıştığını, dış servisin kullanılabilir olduğunu, kaydın hâlâ mevcut olduğunu veya işlemin kesin olarak tamamlandığını göstermez. Bu nedenle araç çağrısından sonra servis yanıtını, durum kodunu ve beklenen sonuç alanlarını da doğrulayın.
Bir parametre doğrulamada başarısız olursa aracı yeniden denemeden önce hatanın türünü ayırın: eksik veya yanlış biçimli veri istemcide düzeltilmelidir; yetki hatası kimlik ve erişim kapsamıyla kontrol edilmelidir; dış servisin reddettiği işlemde ise servis yanıtındaki hata kodu ve ilgili parametre birlikte incelenmelidir.