2011-04-27 35 views
41

Thứ nhất, trang tĩnh được phân phát cho ứng dụng có phải là trang đăng nhập không?backbone.js - xử lý nếu người dùng đăng nhập hoặc không

Thứ hai, mã phía máy chủ của tôi là tốt (nó sẽ không cung cấp bất kỳ dữ liệu nào mà người dùng không thể xem). Nhưng làm cách nào để ứng dụng của tôi biết rằng nếu người dùng chưa đăng nhập, hãy quay lại biểu mẫu đăng nhập?

Trả lời

14

Tôi có một cuộc gọi phụ trợ rằng mã phía máy khách của tôi mà trang tĩnh của tôi (index.php) thực hiện để kiểm tra xem người dùng hiện có đã đăng nhập chưa. Hãy nói rằng bạn có một cuộc gọi phụ trợ tại api/auth/logged_in trả về mã trạng thái HTTP 200 nếu người dùng đang đăng nhập hoặc 400 khác (sử dụng phiên dựa trên cookie):

appController.checkUser(function(isLoggedIn){ 
    if(!isLoggedIn) { 
     window.location.hash = "login";  
    } 

    Backbone.history.start(); 
}); 

... 

window.AppController = Backbone.Controller.extend({ 

    checkUser: function(callback) { 
    var that = this; 

    $.ajax("api/auth/logged_in", { 
     type: "GET", 
     dataType: "json", 
     success: function() { 
     return callback(true); 
     }, 
     error: function() { 
     return callback(false); 
     } 
    }); 
    } 
}); 
+0

Bạn sẽ kiểm tra như thế nào trước khi có bất kỳ dữ liệu nào được nhận? Vì vậy, bất cứ khi nào ứng dụng thực hiện cuộc gọi cho dữ liệu, ứng dụng sẽ kiểm tra xem liệu chúng có được đăng nhập hay không. Nếu không, nó sẽ chuyển đến trang đăng nhập. – Matthew

+9

Nếu bạn muốn thực hiện việc kiểm tra từng cuộc gọi đến chương trình phụ trợ, bạn nên tích hợp với mã phụ trợ của mình. Ví dụ: nếu người dùng không được xác thực cho cuộc gọi * any *, thì bạn có thể trả về một '401 Không được ủy quyền' từ chương trình phụ trợ của mình hoặc một thứ gì đó mà bạn có thể nắm bắt ở phía máy khách. Bằng cách này, bạn không phải thực hiện cuộc gọi riêng để kiểm tra ủy quyền trước mỗi yêu cầu dữ liệu. Trong trường hợp này, bạn có thể sẽ phải ghi đè phương thức 'Backbone.sync' để bắt giữ '401 Không được phép' và phát ra một số sự kiện mà bạn có thể sử dụng để phát hiện xem cuộc gọi phụ trợ có bị hủy hay không. – Sam

+1

Đọc xuống vui lòng ↓ – user2398029

69

tôi sử dụng khái niệm phiên để kiểm soát trạng thái đăng nhập người dùng.

Tôi có một SessionModel và SessionCollection như thế này:

SessionModel = Backbone.Model.extend({ 
    defaults: { 
     sessionId: "", 
     userName: "", 
     password: "", 
     userId: "" 
    }, 

    isAuthorized: function(){ 
     return Boolean(this.get("sessionId")); 
    } 

}); 

On bắt đầu ứng dụng, tôi khởi tạo một biến có sẵn trên toàn cầu, activeSession. Lúc bắt đầu phiên này là trái phép và bất kỳ khung nhìn nào ràng buộc với cá thể mô hình này có thể hiển thị cho phù hợp. Khi đăng nhập, lần đầu tiên tôi đăng xuất bằng cách vô hiệu hóa phiên.

logout = function(){ 
    window.activeSession.id = ""; 
    window.activeSession.clear(); 
} 

Điều này sẽ kích hoạt bất kỳ chế độ xem nào lắng nghe activeSession và sẽ đưa chế độ xem chính của tôi vào nơi đăng nhập. Sau đó tôi lấy tên người dùng và mật khẩu từ người dùng và đặt chúng trên activeSession như sau:

login = function(userName, password){ 
    window.activeSession.set(
     { 
      userName: userName, 
      password: password 
     },{ 
      silent:true 
     } 
    ); 
    window.activeSession.save(); 
} 

Điều này sẽ kích hoạt cập nhật cho máy chủ thông qua backbone.sync. Trên máy chủ, tôi có thiết lập hành động POST tài nguyên phiên để nó kiểm tra tên người dùng và mật khẩu. Nếu hợp lệ, nó điền vào chi tiết người dùng trên phiên, đặt một id phiên duy nhất và xóa mật khẩu và sau đó gửi lại kết quả.

Backbone.sync của tôi sau đó được thiết lập để thêm sessionId của window.activeSession vào bất kỳ yêu cầu gửi đi nào đến máy chủ. Nếu Id phiên không hợp lệ trên máy chủ, nó sẽ gửi lại một HTTP 401, sẽ kích hoạt đăng xuất(), dẫn đến hiển thị lời nhắc đăng nhập.

Chúng tôi chưa thực hiện xong việc này, vì vậy có thể có lỗi trong logic, nhưng về cơ bản, đây là cách chúng tôi tiếp cận nó. Ngoài ra, mã trên không phải là mã thực tế của chúng tôi, vì nó có chứa một chút logic xử lý hơn, nhưng đó là ý chính của nó.

+0

Tôi thực sự đã thay đổi hành vi một chút. Tôi biết tạo các phiên mới bằng sessionCollection.create() và sau đó kích hoạt một thông báo đăng nhập toàn cục có sẵn mà mọi khung nhìn đều có thể nghe. –

+0

Phương pháp của bạn thật tuyệt vời. Bất kỳ cơ hội nào bạn có thể chia sẻ ý chính về mã được cập nhật của bạn? :) – dbau

+0

Thật không may, chúng tôi đã chuyển từ giải pháp này sang cơ chế xác thực riêng biệt (dựa trên cookie hiện tại) do các vấn đề trên chương trình phụ trợ (chúng tôi muốn sử dụng hệ thống xác thực sẵn có trên chương trình phụ trợ) –

-14

Tôi nghĩ rằng bạn nên làm máy chủ này chỉ đứng về phía ... Có rất nhiều cơ hội nhận được nó hack đơn vị và trừ khi bạn có một số loại api tuyệt vời đối phó với nó

+8

Bạn nên làm điều đó bên máy chủ _as well_, nhưng không có gì sai khi phát hiện trạng thái đăng nhập trên máy khách với điều kiện bạn không phụ thuộc vào nó. –

2

Tôi nghĩ bạn không nên chỉ kiểm soát html hiển thị mà còn kiểm soát dữ liệu hiển thị. Bởi vì người dùng có thể sử dụng firefox để thay đổi mã javascript của bạn.

Để biết chi tiết, bạn nên cung cấp cho người dùng mã thông báo sau khi đăng nhập và mỗi khi họ truy cập thành phần của bạn trong trang như lưới dữ liệu hoặc cây hoặc thứ gì đó tương tự, trang phải tìm nạp những dữ liệu này (có thể trong json) từ webservice của bạn và webservice sẽ kiểm tra mã thông báo này, nếu mã thông báo không chính xác hoặc quá hạn do bạn không nên cung cấp dữ liệu người dùng thay vì bạn nên cung cấp thông báo lỗi. Vì vậy, người dùng không thể crack bảo mật của bạn ngay cả khi người đó sử dụng firebug để thay đổi mã js.

Điều đó có thể giúp ích cho bạn.

Các vấn đề liên quan