Giriş sayfasını neden tek bir sayfa uygulamasına ayrı bir sayfa yapalım?

SPA'nın giriş sayfasının SPA sayfası olmayan ayrı bir sayfa olmasının neden popüler göründüğünü merak ediyorum.

Aklıma gelen tek şey güvenlik ama belirli bir güvenlik nedeni olduğunu düşünemiyorum. Aklıma gelen tek şey, eğer giriş sayfanız SPA’nın bir parçasıysa, firebug veya web denetçisi gibi araçlar tarafından görülebilen, ancak normal bir şekilde gönderseniz bile, kullanıcı adınızı / şifrenizi ajax üzerinden göndermesi demek. POST isteği, bu verileri kolayca yakalayabilen başka araçlar da var (kemancı, httpscoop vb.).

Kaçırdığım bir şey mi var?

Muhtemelen , yalnızca uygulama için gerekli olan bir dizi müşteri tarafı varlıkları (ağır JavaScript çerçeveleri, resimler vb. ) Yüklemekten tasarruf etmek mümkündür .

Benzer bir performans hedefine ulaşmak için daha sofistike araçlar var (bkz. " Malte Ubl & John Hjelmstad: JavaScript yüklemesine yeni, etkili bir yaklaşım - JSConf EU 2012 "), ancak bu özellikle, özellikle de etkili bir şekilde uygulanması için oldukça hızlıdır. web uygulamanız zaten tüm varlıklarınızı kullanıyor.

Bunu, http://infogr.am beta gibi bir sitede vahşi ortamda görebilirsiniz :

1. http://infogr.am/login/ yükler jquery , raphael , özel js ve css 3 dosyaları.
2. http://infogr.am/beta/ (uygulamanın ana SPI sayfası) 10 javascript çerçevesi, 5 harici css dosyası ve yaklaşık 60 resim yükler.

Bence ya da aleyhinde bazı makul argümanlar olduğunu düşünüyorum ve teknolojinin de kararda rol oynadığını söyleyebilirim.

Bir "giriş" ayrı bir giriş yapılabiliyorsa "Dizin Güvenliği" nin kullanılmasına izin verilebilir. Genelde herkes giriş "sayfasını" görebilir, ancak yalnızca kimliği doğrulanmış kullanıcılar "sayfa" ve "dizin" uygulamasını görebilirler. Güzergahın kilitlenmesi de mümkündür, burada / Hesap / / Uygulama / 'dan farklıdır ve her birinin kendi güvenlik "profili" vardır.

Ayrıca, bir SPA yaklaşımı kullanıyorsanız ve kimlik doğrulamasını uygulama deneyimiyle karıştırıyorsanız, mantık etkilenebilir. Kullanıcının "burada oldukları için giriş yapmış" olduğunu kabul etmek yerine, sürekli olarak kimlik doğrulama durumlarını kontrol etmeli ve "bu kullanıcı burada mı olmalı" sormalısınız.

Ayrıca, giriş sayfası genel olarak tüketiciye yönelik sitelerdedir. kimlik doğrulaması, tüm hedef kitleye yönlendirilebilir.

Ayrı bir giriş sayfası tutmamın nedeni ve neden “tüketiciyle yüz yüze gelme” sitem için tamamen farklı bir uygulamaya sahip olduğumun nedeni, kimliği doğrulanmamış kişilere çok az maruz kalmamdır. Şans eseri, bazı moronlar giriş sayfama vurmaya başlar, bunun şeylerin uygulama tarafını etkilemesini istemiyorum .. giriş sadece basit bir kimlik doğrulaması araması yapsa bile kullanıcıların tecrübesi .. En kötü durumda, tüketici sitem kapanıyor ve kimse giriş yapamıyor, ama en azından giriş yapan kullanıcılar bilmeyecek ve deneyimleri yavaşlamaya başlamayacak .. Bu kurşun geçirmez bir seçenek değil demiyorum .. ama en azından kimliği doğrulanmamış alana riski izole ettim ..

Bunu yapmanın bir nedeni normal çerez tabanlı oturumları kullanabilmenizdir. Kullanıcı oturum açar, cevap ilk ana sayfayla birlikte çerez gönderir ... ve ardından izleyen tüm ajax çağrıları çerezleri sunucuya geri gönderir.

Bunu yapmak için birkaç neden görüyorum:

1. Web.xml'de normal yol tabanlı erişim kontrolü kurallarını kullanabilirim.
2. Tüm Ajax uygulamamı doğru bir şekilde koruduğumdan asla emin olamam ve kendime emin olmak için kapsamlı testler yapmam gerekiyor.
3. Kimlik doğrulamayı bir çerçeveye (Spring Security gibi), üçüncü taraf bir uygulamaya veya bir SSO çözümüne (CAS veya JOSSO gibi) devredebilirim.
4. Tarayıcının kullanıcı adını ve (isteğe bağlı olarak) kullanıcı için şifreleri önbelleğe almasına izin verebilirim.