Gizli AJAX'ın sahte performans talepleri ne kadar güvenli?

Gizli bir AJAX isteği nedir?

Bir kullanıcının işleminin hemen gerçekleşmesini sağlamak için tasarlanan gizli AJAX isteklerinin kullanımında bir artış olduğunu fark ettim. Bu tip AJAX isteğine bloke edici olmadığına bakacağım. Bu, kullanıcının farkında olduğunu bilmeden yapılan bir AJAX talebidir, arka planda gerçekleştirilir ve çalışması sessizdir ( AJAX çağrısının başarılı bir şekilde tamamlandığını gösteren hiçbir ayrıntı yoktur ). Amaç, işlemin gerçekten bitmediğinde derhal gerçekleştiğini göstermek.

İşte blokaj yapmayan AJAX isteğinin örnekleri;

• Kullanıcı bir e-posta koleksiyonundaki silme tıklaması. Öğeler gelen kutusundan hemen kaybolur ve diğer işlemlere devam edebilirler. Bu arada, bir AJAX talebi arka plandaki öğelerin silinmesini işlemektedir.
• Kullanıcı yeni kayıtlar için bir form doldurur. Tıklamalar kaydet. Yeni öğe hemen listede görünür. Kullanıcı yeni kayıtlar eklemeye devam edebilir.

Açıklığa kavuşturmak için, işte AJAX talebini engelleme örnekleri;

• Kullanıcı bir e-posta koleksiyonundaki silme tıklaması. Bir kum saati imleci belirir. AJAX talebi yapılır ve kum saati imlecine yanıt verdiğinde kapatılır. İşlemin tamamlanması için kullanıcının bir saniye beklemesi gerekir.
• Kullanıcı yeni kayıtlar için bir form doldurur. Tıklamalar kaydet. Bir AJAX yükleyici animasyonu ile form griye döner. "Verileriniz kaydedildi" mesajı görüntülenir ve listede yeni kayıt görünür.

Yukarıdaki iki senaryo arasındaki fark, bloke edici olmayan bir AJAX kurulumunun, bir işletme performansının geri bildirimini sağlamadığı ve bloke edici bir AJAX kurulumunun sağladığıdır.

Gizli AJAX İsteklerinin Riski

Bu AJAX talebi stilinin en büyük riski, AJAX isteği başarısız olduğunda web uygulamasının tamamen farklı bir durumda olabileceğidir.

Örneğin, engelleyici olmayan bir örnek;

• Kullanıcı bir sürü e-posta seçer. Sil düğmesine tıklar. İşlem hemen gerçekleşiyor gibi görünüyor (öğeler listeden kayboluyor). Kullanıcı daha sonra oluştur düğmesine tıklar ve yeni bir e-posta yazmaya başlar. Şu anda, JavaScript kodu, AJAX isteğinin başarısız olduğunu keşfetti. Komut dosyası bir hata mesajı gösterebilir, ancak şu anda gerçekten anlamsız.

Alternatif olarak, engelleyici bir örnek;

• Kullanıcı bir sürü e-posta seçer. Sil düğmesine tıklar. Bir saat camı görür, ancak işlem başarısız olur. "Hata. Falan filan" diyerek hata mesajı alıyorlar. E-posta listesine geri döndürülüyorlar ve hala silmek istedikleri e-postalara sahipler. Onları tekrar silmeye çalışabilirlerdi.

Engellenmeyen AJAX taleplerini yerine getirmenin başka teknik riskleri de vardır. Kullanıcı tarayıcıyı kapatabilir, başka bir web sitesine gidebilir ve mevcut web'deki herhangi bir hatanın içeriğini anlamsız hale getiren başka bir konuma gidebilir.

Peki neden bu kadar popüler oluyor?

Facebook, Google, Microsoft, vb .. vs .. Bütün bu büyük etki giderek işlemlerini yapmak için engellenmeyen AJAX istekleri kullanan görünür anında yapılmaktadır söyledi. Ayrıca form düzenleme editörlerinde kaydetme veya gönderme düğmesi olmayan bir artış gördüm . Bir alandan çıkar çıkmaz ya da enter tuşuna basın. Değer kaydedildi. Profilinizde hiçbir güncelleme mesajı yok veya kaydetme adımı yok.

AJAX talepleri kesin değildir ve tamamlanıncaya kadar başarılı olarak değerlendirilmemelidir, ancak birçok büyük web uygulaması aynı şekilde çalışmaktadır.

Hızlı görünme pahasına gereksiz bir risk alarak duyarlı uygulamaları simüle etmek için engelleyici olmayan AJAX aramalarını kullanan bu web siteleri var mı?

Rekabetçi kalabilmek için hepimizin takip etmesi gereken bir tasarım deseni mı bu?

Gerçek tepki olarak pek "sahte" bir performans değil. Popüler olmasının birkaç nedeni var:

• İnternet bağlantısı bugünlerde oldukça güvenilirdir. Bir AJAX isteğinin başarısız olma riski çok düşük.
• Gerçekleştirilen işlemler gerçekten güvenlik açısından kritik değil. E-postalarınız sunucuda silinmezse, en kötüsü sayfaya bir daha geldiğinizde tekrar silmeniz gerekir.
• İsteğiniz başarısız olursa eylemi geri almak için sayfanızı tasarlayabilirsiniz, ancak sunucuya bağlantınız koptuğu anlamına gelmekle birlikte bu kadar ince olmak zorunda değilsiniz. "Bağlantı koptu. Son değişiklikler kaydedilemiyor. Daha sonra tekrar deneyin." Demek daha kolay.
• Sayfanızı yalnızca bekleyen bir AJAX isteğine izin verecek şekilde tasarlayabilirsiniz, böylece durumunuz sunucudan çok fazla eşitlenemez.
• AJAX isteği beklerken, bir sayfayı kapatmaya ya da bir sayfadan uzaklaşmaya çalışırsanız, tarayıcı sizi uyarır.

Bir şeyin işe yarayacağını varsaymak ve uzak tarafta başarısız olması durumunda bir hatayı görüntülemek, kullanıcının sunucudan yanıt alıncaya kadar başka bir şey yapmasını engellemekten daha kullanıcı dostu olduğunu gösterir.

Bir e-posta istemcisi aslında bunun için mükemmel bir örnek: 5 e-posta ile bir listem var ve en iyisi seçildiğinde DEL, ilk üç e-postanın üç kez vurulduğunda ilk üç e-postanın silinmesini bekliyorum. "Blokaj yapmayan AJAX" ile bu iyi çalışır - tuşa her bastığımda seçilen e-posta hemen kaldırılır. Bir şeyler yanlış giderse bir hata gösterilir ve düzgün şekilde silinmeyen e-postalar tekrar gösterilir VEYA tutarsız yerel durumdan kurtulmak için sayfa yeniden yüklenir.

Yani en yaygın durumda - bu başarı - kullanılabilirliği arttırır. In nadir durumlarda - başarısızlık - kullanılabilirlik (yine silindi eleman gösterileri yukarı veya uygulama "yeniden" olduğu) bozulmuş ama genellikle yaygın durumlar için en iyi kullanılabilirlik istiyorum bir uygulama oluştururken, hatalarıyla durumunda.

Kullanıcılar, yazılımınızın sahnelerin arkasında ne yaptığını umursamıyor: eylemlerinin görünür bir etkiye sahip olmasını ve onların hızında çalışabilmelerini istiyor.

İstemci tarafında bir işlem başarılıysa - e-postaları silmek gibi - sunucu tarafında da başarılı yapmak sizin işinizdir. Silme neden başarısız oldu? Bir tür sınırlamadan kaynaklanıyorsa (örnek olarak, arşivlenmiş bir e-postayı kaldıramazsınız), eylemi başarısızlığa uğramadan önce kullanıcı bunun farkında olmalıdır .

Hata daha ciddi bir şeyden kaynaklanıyorsa (diyelim bir veritabanı çökmesi diyelim), işlemi kaydetmenin ve sistem yeniden başladığında tekrar denemenin bir yolunu bulmalısın.

Bunu yönetmenin iyi bir örneği, Facebook'un sohbeti işleme şeklidir. Bir kullanıcının aniden bağlantısını kesmesini engellemenin bir yolu yoktur; bu, ayrılmadan önce gönderdiğiniz mesajları okuyamayacakları anlamına gelir. Bir hata göstermek yerine, sistem tüm bu mesajları kaydeder ve geri geldiğinde onları kullanıcıya sunar. Veri kaybı olmaz.

İki seçenek arasında uzlaşma sağlayabilirsiniz. Örneğin, kullanıcı bir e-postayı silerse, sunucudan geri bir onay alıncaya kadar kırmızı olarak işaretleyebilir veya gri olarak işaretleyebilir ve yalnızca listeden kaldırabilirsiniz. Kullanıcı bir işlem beklerken hala başka şeyler yapabilir, bu nedenle engelleme yapmaz, ancak yine de kullanıcı için eylemlerinin henüz yerine getirilmediğini hatırlatır.

Amazon AWS bu yaklaşımı benimsemiştir: bir örneği durdurduğunuzda / başlattığınızda, seçmenize olanak sağlayan onay kutusu bir döndürücüye dönüşür (bu nedenle birkaç saniye boyunca hiçbir şey yapamazsınız), ancak bu sizi engellemiyor diğer örneklerle etkileşime girme.

Bunun, Uygulamalar gibi davranmaya çalışan ve tarayıcıda daha fazla işlem yapan (form verilerini doğrulama gibi) daha geleneksel sitelerden daha fazla web sitesiyle bir araya geldiğini düşünüyorum. Kodunuz güvenilir olduğu ve normal şartlarda başarılı olmasını beklediğiniz sürece çok fazla bir sorun görmüyorum.

"Şu anda JavaScript kodunun AJAX isteğinin başarısız olduğunu keşfettiği şu anda bulunuyor. Komut dosyası bir hata mesajı gösterebilir, ancak şu anda gerçekten anlamsızdır."

Neden anlamsız olmalı? E-posta listesine geri dönebilir ve silme işlemini tekrar yapabilirsiniz. Neden bunun yerine bekle? Aslında çok fazla bir "risk" yoktur ve hızlı göründüler, aslında daha hızlı çalışırlar. Öyleyse, faaliyet "kritik" değilse, neden yavaş olmalısınız?

Benim 2c: Ajax operasyonlarını ve diğerlerinin kötü bir tasarım tercihi olduğu “engellemeyen” Ajax işlemlerini yapmanın daha iyi olduğu durumlar. Örnek: bir YouTube videosunu oylama. Orada küçük başlangıçlara tıkladığınızda sayfanın herhangi bir bölümünün engellenmesini gerçekten istemezsiniz. Sessizce başarısız olmak daha iyidir. Bir onay mesajı bile aşırı derecede öldürülebilir. Bununla birlikte, e-posta silme ile ilgili örneğiniz, Ajax engelleme türü isteği için zorunlu olarak nitelendirebilirim.

Mongo DB böyle bir şey yapar (ve bu bir Masaüstü uygulaması örneği olarak düşünülebilir). İşlemleri için çeşitli "Endişeler Yaz" seçeneğine sahiptirler ve başarılı bir ağ transferini onaylayana kadar "hemen geri dönün ve hiçbir şey beklemeyin" den "blok" a kadar her işlem için farklı değerlere yapılandırabilirsiniz. daha sonra geri dönmeden önce içeriğin uzaktaki makineye disk yazması için uygun şekilde planlanmasını bekleyin "". Açıkçası, Mongo sürücüsünü kullanarak Desktop kalın istemcisi (C ++ gibi) yaparsanız, en az "kritik önemde" db işlemleri (yeni e-postaları kontrol etmek gibi) ve diğerleri için daha katı yazma kaygılarıyla ilgili en hafif yazma sorununu belirlersiniz. .

Blokaj yapmayan Ajax'ın faydasını görmeme rağmen, bunun çok fazla olduğu konusunda size katılıyorum. Bir noktada fotoğraf yükleme için bunu yapacak en az bir ünlü "sosyal ağ" sitesi vardı. Yüklemek için fotoğrafınızı seçtiniz ve daha sonra bam, hemen yapılacağını söylerdi ve ertesi gün daha fazla fotoğraf eklemek istediğinizde (veya daha önce eklediğinizi düşündüğünüzde kullandığınızda) yeterince emin olacaksınız. asla bulunamadı. Daha sonra bundan vazgeçtiler ve aslında yanıt beklemek için zaman harcadılar (ve gerçekten de bazen "fotoğraf yüklenemedi, daha sonra tekrar deneyin" gibi mesajlar alırsınız).