2011-10-24 37 views
5

Tôi đang cố gắng phát triển một ứng dụng web javascript thuần túy bằng Dojo. Vấn đề tôi gặp phải là một trong những hạn chế truy cập vào các phần của ứng dụng. Người dùng được xác thực sẽ có thể truy cập mọi thứ, trong khi người dùng không được xác thực chỉ có thể truy cập màn hình đăng nhập.xác thực ứng dụng web dojo

Vấn đề là không có gì (mà tôi biết) sẽ ngăn người dùng mở một thiết bị đầu cuối javascript trình duyệt và nhập một cái gì đó như: app.displayRestrictedContent(); và do đó có quyền truy cập vào màn hình dành cho người dùng được xác thực.

Tôi đã triển khai đăng nhập dựa trên ajax; tất cả các cuộc gọi ajax được bảo đảm bằng một phiên. Vì vậy, trong khi người dùng không được xác thực có thể tải màn hình bị hạn chế, họ sẽ không thể tìm nạp dữ liệu cho nó. Nhưng vẫn còn, Có vẻ như sai cho màn hình này được tùy ý truy cập.

Tôi đang cố gắng làm điều không thể? Nó có vẻ ngớ ngẩn để viết mã như if (user.auth) app.displayRestrictedContent(); khi nó dễ dàng bị phá vỡ. Và điều này khiến tôi tin rằng tôi thiếu một điều gì đó hiển nhiên đối với mọi người khác. Tôi không thể tìm thấy nhiều thông tin ở tất cả các ứng dụng dựa trên javascript thuần túy và các mô hình xác thực.

+0

BTW, phần cuối được thực hiện thông qua cakePhp. – andreb

Trả lời

1

Tôi không phải là chuyên gia, nhưng dưới đây là một số suy nghĩ tôi đã thực hiện về điều này. Tôi không nghĩ rằng bạn đã bỏ lỡ bất cứ điều gì (nếu vậy, tôi có quá) - Tôi nghĩ rằng đây là một vấn đề khá cơ bản với tất cả các ứng dụng của khách hàng, cho dù đó là một thực thi biên dịch hoặc một Javascript.

Tất nhiên, tệp thực thi được biên dịch không bị cản trở bởi nó, vì nó được tạo thành mã máy rất khó đọc hoặc dịch ngược thành bất kỳ thứ gì hữu ích. Tuy nhiên, với Javascript, ứng dụng thường được phân phát chính xác như bạn đã viết, và do đó dễ dàng sửa đổi và giải thích.

Điều đó đưa tôi đến giải pháp bán đầu tiên: làm xáo trộn Javascript của bạn. Nếu bạn sử dụng công cụ xây dựng của Dojo với tham số shrinksafe, tất cả khoảng trống không cần thiết sẽ bị xóa và tất cả các mã định danh được rút ngắn, làm cho mã khó đọc. Tôi gọi đây là một giải pháp bán, một số có thể nói thậm chí điều đó cho nó quá nhiều tín dụng - bản thân tôi vẫn nghĩ rằng nó đáng làm. Sau khi tất cả, mã thu nhỏ tải xuống nhanh hơn quá!

Cách thứ hai tôi thực hiện trong ứng dụng của mình là tách các phần khác nhau thành "tạo lớp". Ví dụ, trong xây dựng hồ sơ của tôi, tôi sẽ có một cái gì đó giống như

dependencies = { 
    .. 
    layers: [ 
     { name: "../myApp/Core.js", resourceName: "myApp.Core", 
      dependencies: ["myApp.Core", "myApp.Foobar"] 
     }, 
     { name: "../myApp/modules/Login.js", resourceName: "myApp.modules.Login", 
      dependencies: ["myApp.modules.Login", "myApp.modules.LoginUi"...], 
      layerDependencies: ["../myApp/Core.js"] 
     }, 
     { name: "../myApp/modules/Secret.js", resourceName: "myApp.modules.Secret", 
      dependencies: ["myApp.modules.Secret", "myApp.modules.SecretUi"], 
      layerDependencies: ["../myApp/Core.js"], 
      authentication: 42 
     } 
    ] 
} 

Bây giờ, thay vì phục vụ các tập tin JS xây dựng trực tiếp như các tập tin tĩnh, tôi để cho các yêu cầu đi qua một bộ điều khiển trong ứng dụng server-side của tôi, kiểm tra xem lớp JS có yêu cầu xác thực hay không và người dùng có đăng nhập bằng truy cập cần thiết hay không.

Điều này có một số điểm nhất định. Các tệp JS không được lưu trữ và nếu tôi có tất cả JS của mình trong một lớp xây dựng, ứng dụng có thể tải nhanh hơn một chút.Tất nhiên cũng có giới hạn về độ sắc thái của nó khi tạo các lớp. Nhiều lớp hơn có nghĩa là rắc rối hơn, nhưng cũng truy cập mô-đun hạt mịn hơn.

Tôi muốn được nghe những người khác trò chuyện về điều này. Đó là một câu hỏi hay.

+0

Cảm ơn. Đây là thông tin tốt. – andreb

+0

Bạn có thể nói thêm về hệ thống phân lớp và xác thực mà bạn sử dụng để lấy lại tài sản js về trình duyệt không? – andreb

1

Khi người dùng đăng nhập thành công các máy chủ nên cung cấp anh ta với một phiên thẻ. Sau đó, bất cứ khi nào người dùng yêu cầu một tài nguyên (hoặc thông qua chỉ chuyển hướng trình duyệt hoặc qua AJAX), anh ta hiển thị máy chủ mã thông báo phiên của mình (bằng cách lưu trữ nó trong cookie và tự động gửi nó trên tất cả các yêu cầu hoặc bằng cách chuyển nó một cách rõ ràng yêu cầu AJAX)

Máy chủ có thể sử dụng mã thông báo phiên từ người dùng để kiểm soát ủy quyền phía máy chủ, từ chối mọi yêu cầu có mã thông báo không hợp lệ hoặc lỗi thời.

https://en.wikipedia.org/wiki/HTTP_cookie#Session_management

+0

Cảm ơn, tôi có kiến ​​thức làm việc về các phiên. Câu hỏi liên quan trực tiếp đến tính chất phía máy khách của các ứng dụng Javascript và cách người dùng không được ủy quyền có thể truy cập các khu vực bị hạn chế. – andreb

+1

Đó là những gì tôi đã nói. Ở phía máy khách, bạn có thể giữ một mã định danh phiên mà bạn có thể sử dụng để xác thực chính mình. Ở phía máy chủ, bạn cho phép truy cập vào các tài nguyên dựa trên các định danh phiên được trình bày (và điều này cần phải được thực hiện ở phía máy chủ - máy khách không thể tin cậy được). (BTW, tôi không thấy câu trả lời được chấp nhận có liên quan đến xác thực như thế nào - nó chỉ nói về hệ thống xây dựng dojo và nó rất dễ dàng để làm việc xung quanh Javascript nén) – hugomg

+0

Câu trả lời cung cấp thông tin chi tiết về việc phát triển một ứng dụng javascript sử dụng Dojo, đó là những gì tôi đang làm. Câu trả lời đã giải quyết câu hỏi của tôi theo một cách cụ thể. – andreb

2
But still, It seems wrong for this screen to be arbitrarily accessible. 

Vì đó là mã phía máy khách. Bất cứ điều gì bạn viết trong js, hoặc được biên dịch sang js, mong đợi nó có thể đọc được bởi người dùng.

Am I trying to do the impossible? 

bạn có thể tải động mô-đun js sau khi người dùng xác thực. Vì vậy, lúc đầu, chỉ cần tải 1 mô-đun đăng nhập. Khi người dùng đăng nhập, nếu thành công, máy chủ trả về danh sách các mô-đun js để tải, nếu không, trả về danh sách trống. Nó cũng giúp cải thiện thời gian tải khi người dùng truy cập vào trang web của bạn.

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