Tại sao làm cho trang đăng nhập vào một ứng dụng trang thành một trang riêng?

Tôi tự hỏi tại sao nó có vẻ phổ biến khi trang đăng nhập của SPA là một trang riêng không phải là trang của SPA (như được tải và gửi dữ liệu thông qua các yêu cầu ajax)?

Tôi chỉ có thể nghĩ về bảo mật nhưng tôi không thể nghĩ ra một lý do bảo mật cụ thể. Ý tôi là điều duy nhất nảy ra là nếu trang đăng nhập của bạn trong một phần của SPA, nó sẽ gửi tên người dùng / mật khẩu thông qua ajax có thể được nhìn thấy bởi các công cụ như fireorms hoặc trình kiểm tra web ngay cả khi bạn gửi nó như một bình thường Yêu cầu POST, có những công cụ khác có thể dễ dàng nắm bắt dữ liệu này (như fiddler, httpscoop, v.v ...).

Có điều gì tôi đang thiếu?

Có lẽ đó là để tiết kiệm tải một loạt các tài sản phía máy khách (như khung JavaScript nặng, hình ảnh, v.v. ) mà ứng dụng chỉ yêu cầu.

Có nhiều phương tiện tinh vi hơn để đạt được mục tiêu hiệu suất tương tự (xem " Malte Ubl & John Hjelmstad: Cách tiếp cận mới, hiệu quả để tải JavaScript - JSConf EU 2012 ") nhưng điều này khá nhanh để thực hiện và được cho là hiệu quả, đặc biệt là ứng dụng web của bạn sử dụng gần như tất cả các tài sản của bạn.

Bạn có thể thấy điều này trong tự nhiên trong một trang web như http://infogr.am beta:

1. http://infogr.am/login/ tải jquery , raphael , js tùy chỉnh và 3 tệp css.
2. http://infogr.am/beta/ (trang SPI chính cho ứng dụng) tải 10 khung javascript, 5 tệp css bên ngoài và khoảng 60 hình ảnh.

Tôi nghĩ rằng có một số lý lẽ hợp lý cho hoặc chống lại, và tôi muốn nói rằng công nghệ cũng đóng một vai trò trong quyết định.

Người ta có thể lập luận rằng có một "trang" đăng nhập riêng cho phép sử dụng "Bảo mật thư mục". Nói chung, bất cứ ai cũng có thể xem "trang" đăng nhập, nhưng chỉ người dùng được xác thực mới có thể xem "thư mục" của ứng dụng và đó là "thư mục". Tuyến cũng có thể bị khóa, trong đó / Tài khoản / khác với / Ứng dụng / và mỗi tài khoản có "hồ sơ" bảo mật riêng.

Ngoài ra, nếu bạn đang sử dụng phương pháp SPA và bạn đang trộn xác thực với trải nghiệm ứng dụng, logic có thể bị sai lệch. Thay vì cho rằng người dùng đã "đăng nhập vì họ ở đây", bạn phải liên tục kiểm tra trạng thái xác thực của họ và hỏi "người dùng này có nên ở đây không".

Ngoài ra, trang đăng nhập thường nằm trên trang web đối mặt với người tiêu dùng .. bạn truy cập www.yourapp.com và nó có một số thông tin, liên hệ, hỗ trợ, v.v. và trang "đăng nhập" .. từ trang đăng nhập, sau xác thực, bạn có thể chuyển hướng đến một loạt các mục tiêu ..

Lý do tôi giữ một trang đăng nhập riêng và tại sao tôi thực sự có một ứng dụng hoàn toàn khác cho trang web "đối mặt với người tiêu dùng" của mình là vì tôi có thể tiếp xúc rất ít với người không được xác thực. Tình cờ một số kẻ biến thái bắt đầu đập vào trang đăng nhập của tôi, tôi không muốn điều đó ảnh hưởng đến khía cạnh ứng dụng của mọi thứ .. ngay cả khi đăng nhập chỉ thực hiện tra cứu xác thực đơn giản .. nó giúp tôi giữ cho bozo không ảnh hưởng đến tôi Trải nghiệm người dùng .. Trường hợp xấu nhất, trang web tiêu dùng của tôi bị sập và không ai có thể đăng nhập, nhưng ít nhất người dùng đã đăng nhập sẽ không biết và trải nghiệm của họ sẽ không bắt đầu chậm lại .. Tôi không nói đó là lựa chọn chống đạn .. nhưng ít nhất là Tôi đã cô lập nguy cơ cho khu vực không được xác thực ..

Một lý do để làm điều này là vì sau đó bạn có thể sử dụng các phiên dựa trên cookie bình thường. Người dùng đăng nhập, phản hồi gửi cookie cùng với trang chính ban đầu ... và sau đó tất cả các cuộc gọi ajax tiếp theo sẽ gửi cookie trở lại máy chủ.

Tôi thấy một vài lý do để làm điều này:

1. Tôi có thể sử dụng các quy tắc kiểm soát truy cập dựa trên đường dẫn thông thường trong web.xml.
2. Tôi không bao giờ có thể chắc chắn rằng tôi đã bảo vệ toàn bộ ứng dụng Ajax của mình đúng cách và tôi cần thực hiện các bài kiểm tra mở rộng để tự tin.
3. Tôi có thể ủy quyền xác thực cho một khung (như Spring Security), ứng dụng của bên thứ ba hoặc giải pháp SSO (như CAS hoặc JOSSO).
4. Tôi có thể để tên người dùng lưu trữ bộ nhớ cache và mật khẩu (tùy chọn) cho người dùng.