Güvenlik kısıtlamaları bir hizmetin boş olmasına veya bir istisna atmasına neden olmalı mı? [kapalı]

Bu konuda daha deneyimli bir geliştirici ile biraz anlaşmazlık yaşıyorum ve başkalarının bu konuda ne düşündüğünü merak ediyorum; ortamımız Java, EJB 3, hizmetler vb.

Yazdığım kod, bir şeyler almak ve bir şeyler yaratmak için bir servisi çağırıyor. Karşılaştığım sorun, anlamlı olmayan boş gösterici istisnalarım oldu. Örneğin, hizmetten bir nesne oluşturmasını istediğimde, null geri alıyorum; Bilinen geçerli bir kimliği olan bir nesneyi aramaya çalıştığımda null değerini geri alıyorum. Kodumda neyin yanlış olduğunu anlamaya çalışırken biraz zaman geçirdim; daha az tecrübeli olduğum için genellikle yanlış bir şey yaptığımı varsayıyorum, ama bu sıfır getirinin güvenlik olduğu ortaya çıkıyor. Hizmetimi kullanan kullanıcı sorumlusu hedef hizmet için doğru izinlere sahip değilse, yalnızca null değerini döndürür. Buradaki diğer hizmetlerin çoğu da çok iyi belgelenmemiş, bu yüzden görünüşe göre bu sadece bilmeniz gereken bir şey.

Bu, hizmetle etkileşim kuran bir geliştirici yazma kodu olarak oldukça kafa karıştırıcıdır. Hizmetin, kullanıcının bu şeyi yüklemek veya bu şeyi oluşturmak için uygun izinlere sahip olmadığını söyleyecek bir istisna olması benim için çok daha mantıklı olacaktır; O zaman hemen servisimin neden beklendiği gibi çalışmadığını anlayacağım.

Hizmeti yazan daha deneyimli geliştirici, veri istemenin bir hata koşulu olmadığını ve istisnaların, kullanıcının verilere erişimi olmadığında değil, yalnızca bir hata durumunda atılması gerektiğini savundu. Bu veriler genellikle bir GUI'de aranır ve doğru izinleri olmayan kullanıcılar için bu şeyler yalnızca "mevcut değildir". Kısacası: sormak yanlış değil, bu yüzden istisna yok. Yöntemleri boş döndür çünkü bu kullanıcılara bu şeyler "yok". Oluşturma yöntemleri, kullanıcının bu şeyi oluşturmasına izin verilmediğinde null değerini döndürür.

Bu normal ve / veya iyi bir uygulama mı? İstisnaları kullanmayı tercih ediyorum çünkü neler olduğunu bilmek daha kolay. Bu nedenle, örneğin, geçersiz kimliğe sahip bir nesneyi null döndürmektense sorduğunuzda bir NotFoundException oluşturmayı da tercih ederim.

İstisnalar yalnızca bir hata olduğunda ve bir şey istemek hata olmadığında atılmalıdır.

Bir şey istemek bir hata olmayabilir, ancak istediğiniz bir şeye izin vermemek kesinlikle bir çeşit hatadır. İstisnalar, özel dönüş değerleri yerine kullanılacak istisnai durumları bildirmenin alternatif bir yoludur (örneğin null, yazdığınız gibi, işlerin ters gitmesinin 1 olası nedeni varsa ( Tam olarak 1 olası neden, bir sonraki sürümde 2 olası neden olabilir, bu nedenle nullbaşarısızlığı gösteren bir dönüş değeri olarak kullanmak kendinizi köşeye boyamak olacaktır)). Hizmet neden istediğinizi yapmayacağını hiçbir şekilde bildirmezse, kesinlikle kötü bir tasarımdır.

Özel bir dönüş değerinin kullanılıp kullanılmayacağı (örneğin, negatif tamsayılar normalde negatif olmayan bir tamsayı döndüren işlevler için yararlıdır), bir istisna, genel bir hata işleyici veya logger vb., Sonunda bir uygulama detayıdır. Seçim dile, duruma, sözleşmelere bağlıdır ve aynı zamanda bir zevk meselesidir. Ana nokta olması gerektiğidir bazı bulmanın doğrudan bir yolu neden bir şey çalışmaz. Aksi takdirde, tek seçeneğiniz farklı seçeneklerle ve kara kutunun davranışı ile neyin ilişkili olduğunu bulmak için ne olursa olsun, zaman kaybıdır.

String.substring()IndexOutOfBoundsExceptionindeks sınırların dışındaysa bir atar . Bunun nullyerine geri dönmenin herhangi bir avantajını düşünemiyorum - felsefi olarak - biri Stringsınırlarının dışında bir şey içermediğini iddia edebilir , bu yüzden nullmantıklı bir dönüş değeri olacaktır. Mantıksal-felsefi ve pratik olmak açıkçası iki farklı hayvandır.

Sözleşmenin ne olduğu ile ilgili. Sözleşmenizde olmayan bir şey talep edebileceğinizi söylüyorsa, ne olduğunu (null veya null nesne) söylemelidir.

Öte yandan, sözleşmeniz önce farklı bir yöntem çağırmanız ( DoesSomethingExist()) ve ardından Getyöntemi çağırmanız gerektiğini söylüyorsa, sözleşmeniz yalnızca var olan şeyleri alabileceğinizi ve yoksa bir istisna atabileceğinizi söyleyebilir. İstisna mesajı, DoesSomethingExist()yararlı bir hata mesajı olan "Önce aradığınızdan emin olun" gibi bir şey söyleyebilir .

Sorunun tek bir boyutuna uyan tek yanı yoktur. İstisnaların kullanılıp kullanılmayacağı veya null değerinin döndürüleceği duruma bağlıdır.

Buna sadece dogmatik bir bakış açısından bakmak yerine, arayüze bir kullanıcı arayüzü olarak bakın . Kullanıcı arayüzleri kullanılabilir olmalıdır . Dolayısıyla, bir şeyi yapmanın "doğru" yolu hakkındaki kendi görüşleriniz ne olursa olsun, arayüzünüzü kullanan birinin bakış açısından en kullanışlı olan yöntemi seçin.

Arayanın neden bir nesnenin döndürülmediğini bilmesi gerekiyorsa, bir istisna uygundur. Bununla birlikte, genel kavram "izniniz yoksa, mevcut değildir" ise, null değeri kabul edilebilir.

Özellikle sizin durumunuzda, arayan kişinin ilk olarak oturum açması veya sunucuya bağlanması gerekiyorsa, bir öğeyi aramak için null değerlerinin kabul edilebilir olduğunu söyleyebilirim. O zaman izniniz olduğu veya izniniz olmadığı söylenir. Kapıyı geçtikten sonra, bir şey ararken, izniniz olmadığına (hatta var olduğunu bile bilmenize) izin vermeniz mantıklıdır.

Öte yandan, ilk bağlantınız veya oturum açma adımınız yoksa, bir istisna mantıklıdır. Arayan bir öğenin var olduğunu biliyorsa ve öğeyi geri alamıyorsa API yalnızca boş bir değer döndürmek için yardımcı olmaz.

Bununla birlikte, bir öğe oluşturmak için bu farklı bir hikaye. Muhtemelen başarısız olmasının birçok nedeni olabilir - izinler, kötü parametreler, sunucu belleği yetersiz, vb. .

Bu nedenle, soruyu cevaplamak için, hizmeti kullanan biri açısından kendinize en uygun çözümün ne olduğunu sorun. Onu kullanma şekliniz atipik olabilir ve en yaygın durumda null doğru cevaptır.

Bu yüzden, dini bir savaşa girmeyin, bu sorun için neyin doğru olduğuna karar verin.

Kesinlikle kötü bir tasarım olduğunu düşünüyorum . Boş gösterici benim için geçerli bir cevap değil ve yönetimi zor olabilir.

Kullanıcı uygun bir kimlik bilgisi olmadan bir hizmeti bağlamaya çalışırsa, açık ve öz bir cevapla cevap vermeliyim. Cevap bir istisna veya özel bir nesne olabilir, ancak boş olamaz.

Ağ bağlantısı koptuğunda veya beklenmeyen diğer kritik arızalarda null cevabı bırakmalısınız.

Dahası, null değerine sahip olduğunuzu anlamak için harcadığınız zaman güçlü bir argüman. Herhangi bir kod parçasını anlamak ve kullanmak kolay olmalıdır. Boş bir değere sahip olmak durum böyle değildir.

İyi yazılım tasarımı göz önünde bulundurarak, projenizin ömrü hakkında düşünmelisiniz.
Söylendiği gibi null, geri dönerek müşteriye herhangi bir bilgi vermezsiniz. Bak sana ne oldu, ilk başta sorunun nerede olduğunu fark etmedin. Ayrıca, herhangi bir belge verilmezse, bu bir karışıklıktır.

Bir istisna atarak neyin yanlış gittiğini anlayabilirsiniz. İsterseniz, görüntülenen metni daha spesifik olacak şekilde özelleştirebilirsiniz.

Diğer taraftan, geri dönerek nullmüşteriye neler olup bittiğini araştırmasını sağlayabilirsiniz.

Ayrıca, başka bir yerde olduğunuz için bir sorun olduğunu fark ettiniz NullPointerException. Şimdi bu işlevin geri dönüşünü kaydetmediğinizi hayal edin ... Bu işleve yapılan her çağrıyı bir if elseblokla kuşatmak zorunda kalacaksınız ...

Benim açımdan, geri dönmek nullkötü bir uygulamadır.

Hizmeti yazan daha deneyimli geliştirici, veri istemenin bir hata koşulu olmadığını ve istisnaların, kullanıcının verilere erişimi olmadığında değil, yalnızca bir hata durumunda atılması gerektiğini savundu.

Benim açımdan, bu hiç mantıklı değil.

İzinsiz veriler için sorgulama gereken bir olduğu için, özel duruma neden beklenmedik hiçbir sonuç elde etmek - - Uygun erişimi olmadan sonucu.

Analoji : GETYetkisiz bir yanıt kodu200 ok veri içermiyor, aslında 401 Unauthorized.

Null değeri döndürmek harika değil. Size hiçbir şey söylemiyor. Örneğin, bir uygulama bir şey aramaya çalışıyorsa ve her iki güvenlik sorunu için yanıt boşsa ve öğe yoksa, ikisi arasındaki farkı nasıl anlarsınız?

Anlamlı bir yanıt, uygulamanın bir sonraki adımda ne yapılacağı veya sorunların nasıl çözüleceği hakkında mantıklı seçimler yapmasına izin verebilir.

Kök neden kimliği doğrulanmamış bir kullanıcıysa, belki de güzel bir mesaj sayfasına yönlendiren (ve önemseyen birine bir bildirim) sert bir HTTP 401 yanıtı tercih ederim. Yetkilendirmeyle ilgili nedenler daha fazla durumdur; HTTP yanıtlarını döndürme argümanları (403, mesela) ve servis yanıtında özel olarak oluşturulmuş kodları / mesajları döndürme argümanları vardır.

İstisnalar yalnızca istisnai durumlarda kullanılmalı ve bir şeylerin yanlış gittiği anlamına gelmelidir. Aşırı yüklenmeleri gerektiğini "izin verilmiyor" demek için katılmıyorum. (Aynı değer null dönüş değeri için de geçerlidir: "izin verilmiyor" anlamına gelmesi için katılmıyorum.)

Şeytanlar savunucusu oynamak için boş dönen tarafını almaya çalışacağım.

Benim düşünceme göre, bu tür bir yanıtın neredeyse kabul edilebilir olduğu tek bir durum vardır ve bu durumda, güvenlik söz konusu olduğunda.

Yetkisiz kişilerin bilmemesi gereken sistemle ilgili ayrıntıları yanlışlıkla vermek çok kolaydır. Bundan kaçınılmalıdır.

Örneğin, bir kullanıcı adı ve parola denetleyicisi alın. Ayrı hata kodları olarak bir "Kullanıcı adı bulunamadı" hatası ve "Yanlış şifre" hatası döndürmek, öncelikle geçerli bir kullanıcı adı arayabilir ve ardından bir şifre arayabileceğinden, sizi ciddi güvenlik sorunlarına açacaktır. Genel bir "Geçersiz kullanıcı adı / şifre" döndürmek daha iyi bir seçenek olacaktır.

Böylece, bu özel durumda geri dönmek için neredeyse tamam olduğunu söyleyebilirim nullama katılıyorum, çalışmak çok tatsız olurdu.

Ben dönüş null düşmanca olduğunu düşünüyorum, istemci bu yöntemi çağırmak ve null dönmek, istemci ne olduğunu ve neden null döndü bilmiyorum. Bu nedenle, mantıklı olan ve bu yürütmeyi tanımlamak için bir belge sağlayan yürütme atmalıyız.