เหตุใดจึงทำให้หน้าล็อกอินเป็นแอปพลิเคชันหน้าเดียวเป็นหน้าแยก

ฉันสงสัยว่าทำไมมันจึงเป็นที่นิยมที่จะมีหน้าเข้าสู่ระบบของสปาเป็นหน้าแยกที่ไม่ใช่หน้าของสปา (ในขณะที่โหลดและส่งข้อมูลผ่านคำขอ ajax)?

สิ่งเดียวที่ฉันคิดได้คือความปลอดภัย แต่ฉันไม่สามารถคิดเหตุผลด้านความปลอดภัยที่เฉพาะเจาะจงได้ ฉันหมายถึงสิ่งเดียวที่นึกได้คือหากหน้าเข้าสู่ระบบของคุณในส่วนของ SPA จะส่งชื่อผู้ใช้ / รหัสผ่านผ่าน ajax ซึ่งเครื่องมือดังกล่าวสามารถมองเห็นได้เช่น firebug หรือ web inspector ถึงแม้ว่าคุณจะส่งตามปกติ คำขอ POST มีเครื่องมืออื่น ๆ ที่สามารถรวบรวมข้อมูลนี้ได้อย่างง่ายดาย (เช่นพู้ทำเล่น, httpscoop, ฯลฯ ... )

มีบางอย่างที่ฉันขาดหายไปหรือไม่?

สมมุติว่าเป็นการบันทึกการโหลดเนื้อหาฝั่งไคลเอ็นต์ (เช่นเฟรมเวิร์ก JavaScript, รูปภาพและอื่น ๆ ) ที่แอปพลิเคชันต้องการเท่านั้น

มีวิธีการที่ซับซ้อนกว่าเพื่อให้บรรลุเป้าหมายด้านประสิทธิภาพที่คล้ายกัน (ดูที่ " Malte Ubl และ John Hjelmstad: วิธีการใหม่ที่มีประสิทธิภาพในการโหลด JavaScript - JSConf EU 2012 ") แต่วิธีนี้ค่อนข้างรวดเร็วในการใช้งานและมีประสิทธิภาพ แอปพลิเคชันเว็บของคุณใช้เนื้อหาเกือบทั้งหมดอยู่แล้ว

คุณสามารถดูสิ่งนี้ได้ในเว็บไซต์เช่นhttp://infogr.amเบต้า:

1. http://infogr.am/login/โหลด jquery , raphael , js ที่กำหนดเองและไฟล์ 3 css
2. http://infogr.am/beta/ (หน้า SPI หลักสำหรับแอปพลิเคชัน) โหลดเฟรมเวิร์ก javascript 10 เฟรม, ไฟล์ css ภายนอก 5 ไฟล์และรูปภาพประมาณ 60 ภาพ

ฉันคิดว่ามีข้อโต้แย้งที่สมเหตุสมผลสำหรับหรือต่อต้านและฉันจะบอกว่าเทคโนโลยีมีบทบาทในการตัดสินใจเช่นกัน

หนึ่งอาจโต้แย้งว่ามี "หน้า" เข้าสู่ระบบที่แยกต่างหากช่วยให้การใช้ "ความปลอดภัยของไดเรกทอรี" โดยทั่วไปแล้วทุกคนสามารถเห็นล็อกอิน "หน้า" แต่มีเพียงผู้ใช้ที่ผ่านการตรวจสอบแล้วเท่านั้นที่สามารถดูแอปพลิเคชัน "หน้า" และเป็น "ไดเรกทอรี" เส้นทางของยังสามารถล็อคได้โดยที่ / บัญชี / แตกต่างจาก / แอพ / และแต่ละคนมี "โปรไฟล์" ความปลอดภัยของตัวเอง

นอกจากนี้หากคุณใช้วิธี SPA และคุณกำลังผสมการรับรองความถูกต้องกับประสบการณ์แอปพลิเคชันตรรกะอาจทำให้เกิดความสับสน แทนที่จะสมมติว่าผู้ใช้นั้น "เข้าสู่ระบบเพราะพวกเขาอยู่ที่นี่" คุณต้องตรวจสอบสถานะการรับรองความถูกต้องของพวกเขาอย่างต่อเนื่องและถามว่า "ผู้ใช้รายนี้ควรมาที่นี่หรือไม่"

นอกจากนี้หน้าเข้าสู่ระบบโดยทั่วไปบนเว็บไซต์ผู้บริโภค .. คุณไปที่ www.yourapp.com และมีข้อมูลเกี่ยวกับการติดต่อการสนับสนุน ฯลฯ และหน้า "เข้าสู่ระบบ" จากหน้าเข้าสู่ระบบหลังจาก การรับรองความถูกต้องคุณสามารถเปลี่ยนเส้นทางไปยังโฮสต์ทั้งหมดของเป้าหมาย ..

เหตุผลที่ฉันเก็บหน้าเข้าสู่ระบบแยกต่างหากและสาเหตุที่ฉันมีแอพที่แตกต่างกันโดยสิ้นเชิงสำหรับเว็บไซต์ "ผู้บริโภคหันหน้าไปทาง" ของฉันก็เพราะฉันสามารถเปิดเผยให้ผู้ที่ไม่ได้รับการรับรองความถูกต้องได้น้อยมาก โดยบังเอิญมีบางคนเริ่มจู่โจมในหน้าเข้าสู่ระบบของฉันฉันไม่ต้องการที่จะส่งผลกระทบต่อด้านแอพของสิ่งต่าง ๆ .. แม้ว่าการเข้าสู่ระบบจะทำการค้นหาแบบง่าย ๆ เท่านั้น .. มันช่วยให้ Bozo ไม่ส่งผลกระทบต่อฉัน ประสบการณ์ผู้ใช้ .. กรณีที่แย่ที่สุดเว็บไซต์ผู้บริโภคของฉันล่มและไม่มีใครสามารถเข้าสู่ระบบได้ แต่อย่างน้อยผู้ใช้ที่เข้าสู่ระบบจะไม่ทราบและประสบการณ์ของพวกเขาจะไม่เริ่มช้าลง .. ฉันไม่ได้บอกว่าเป็นตัวเลือกกระสุน ฉันแยกความเสี่ยงไปยังพื้นที่ที่ไม่มีการตรวจสอบสิทธิ์ ..

เหตุผลหนึ่งที่ต้องทำเช่นนี้ก็เพราะคุณสามารถใช้เซสชันตามคุกกี้ปกติ ผู้ใช้เข้าสู่ระบบการตอบสนองส่งคุกกี้พร้อมกับหน้าหลักเริ่มต้น ... จากนั้นการโทร ajax ที่ตามมาทั้งหมดจะส่งคุกกี้กลับไปที่เซิร์ฟเวอร์

ฉันเห็นเหตุผลสองสามข้อที่จะทำสิ่งนี้:

1. ฉันสามารถใช้กฎการควบคุมการเข้าถึงตามเส้นทางปกติใน web.xml
2. ฉันไม่สามารถมั่นใจได้ว่าฉันได้ป้องกันแอปพลิเคชัน Ajax ทั้งหมดของฉันอย่างถูกต้องและฉันต้องทำการทดสอบอย่างละเอียดเพื่อให้มั่นใจ
3. ฉันสามารถมอบสิทธิ์การรับรองความถูกต้องให้กับเฟรมเวิร์ก (เช่น Spring Security), แอปพลิเคชันบุคคลที่สามหรือโซลูชัน SSO (เช่น CAS หรือ JOSSO)
4. ฉันสามารถให้ชื่อผู้ใช้แคชของเบราว์เซอร์และรหัสผ่าน (ทางเลือก) สำหรับผู้ใช้