2012-11-28 25 views
5

Tôi đã triển khai Improved Persistent Login Cookie Best Practice cho tùy chọn "nhớ tôi".Làm cách nào để kết hợp cookie đăng nhập liên tục với các yêu cầu AJAX song song?

Tính năng này hoạt động tốt khi có yêu cầu theo thứ tự (tải trang truyền thống). Trong trường hợp này, bạn chắc chắn rằng yêu cầu tiếp theo sẽ có cùng số nhận dạng chuỗi và mã thông báo được máy chủ gửi lần cuối.

Nhưng trong trường hợp yêu cầu AJAX, khi nhiều yêu cầu đến song song với cùng một trình duyệt, yêu cầu đầu tiên sẽ dẫn đến việc tạo mã số mã thông báo mới. Nhưng các yêu cầu khác sẽ không có số mã thông báo mới được tạo này và chúng tôi sẽ từ chối truy cập coi đó là hành vi trộm cắp.

Làm cách nào để khắc phục sự cố này?

+0

Đối với những gì nó có giá trị, một sợi trên cùng một vấn đề trong Drupal: http://drupal.org/node/327263 (không có giải pháp) – smhg

+0

Trong khi chờ đợi trên đó chủ đề Drupal một giải pháp đã được đề xuất! – bluegaspode

Trả lời

0

Tôi nghĩ bạn nhầm lẫn nhớ tôi với mã thông báo bảo vệ CSRF (Yêu cầu trang web chéo yêu cầu). Mã thông báo CSRF bảo vệ ứng dụng bằng cách vô hiệu hóa khả năng "thực thi chức năng" chưa được xác thực. Và họ làm điều đó bằng cách phát hành mã thông báo không thể hủy bỏ cho mỗi câu trả lời và xác minh nó khi nhận lại yêu cầu.

Hãy nhớ tính năng của tôi là tính năng cho phép người dùng đăng nhập, ngay cả khi phiên ban đầu đã biến mất. Không cần cung cấp lại tên người dùng/mật khẩu của mình. Bạn nên đặt mã thông báo ghi nhớ cho tôi, một lần hoặc một lần vào mỗi lần đăng nhập thành công. Không phải trong mọi câu trả lời. Bạn không đặt cookie phiên trong mọi câu trả lời tại sao bạn lại đặt mã thông báo cho tôi?

+0

Tôi đã đặt liên kết đến câu hỏi sai. Xin lỗi vì sự nhầm lẫn. Tôi đã cập nhật liên kết ngay bây giờ. – Dhiraj

+0

Vẫn câu hỏi tương tự giữ lý do tại sao bạn muốn phát hành chuỗi mới trên MỌI yêu cầu? Và không phải trên đăng nhập? – fatfredyy

+0

@fatfreddy Nếu chúng ta tạo ra một thẻ nhớ tôi khi đăng nhập chỉ, sau đó nếu nó bị đánh cắp và ai đó gửi yêu cầu với mã thông báo này, thì anh ta có quyền truy cập vào hệ thống và không có cách nào để phát hiện xem mã thông báo có bị đánh cắp hay không. Tạo mã thông báo mới với mọi yêu cầu sẽ giúp bạn nắm bắt được điều đó. Nó được mô tả tốt trong bài viết này [http://jaspan.com/improved_persistent_login_cookie_best_practice] – Dhiraj

0

Tôi đã đọc một chút về điều này vì tôi có cùng một vấn đề.

Kỹ thuật của Barry Jaspan và Charles Miller dường như không sử dụng được (đặc biệt là trong các thiết lập AJAX) do thực tế là tạo mã thông báo mới trên máy chủ và áp dụng điều đó trong cookie.

Trong trường hợp của chúng tôi, bản chất không đồng bộ, nhưng có thể có các trường hợp khác mà giá trị không kết thúc trong cookie khi được lưu trữ trên máy chủ (ví dụ: điều hướng khỏi trang trước khi tải).

Barry có vẻ như acknowledge this.

Thứ hai, mã thông báo không hợp lệ (ví dụ: về thay đổi mật khẩu) khiến bạn kết thúc bằng nhiều cookie "ma". Mỗi truy cập với một trong số họ vô hiệu hóa tất cả các phiên khác (đó là tại thời điểm đó có khả năng có những người hợp lệ trong số đó).

Do những hạn chế, tôi nghĩ rằng giải pháp tốt nhất là sự kết hợp của:

  • HTTPS (SSL) sử dụng
  • kỹ thuật này, nhưng mà không tái tạo trên mọi yêu cầu
  • theo dõi vô hiệu bởi người dùng (để xử lý nhận xét thứ hai ở trên)
  • cookie chỉ sử dụng HTTP (để tránh truy cập tập lệnh cho họ)

Tôi đã gửi một tin nhắn tới Barry để xem xét thông báo về điều này trên trang của anh ấy.

1

Dựa trên giải pháp được đề xuất trên chuỗi Drupal nói trên (https://www.drupal.org/node/327263#comment-3428038), tôi tự hỏi liệu chúng tôi không thể có một thuật toán đơn giản hơn.

Thay vì lưu trữ mã thông báo được thay thế "cũ" trong bảng bộ đệm ẩn ngắn, tại sao không sử dụng phiên người dùng hiện tại?

1. User logs in with PL cookie 
If series & token are in PL table: 
    2. User session is populated with the last valid token 
    3. new token is given to client 
    4. user is logged in 
If series key is in PL table, but token is not: 
    2. check if current user session still holds the latest replaced token 
    If found: 
    3. user is logged in. No new token is provided since one was generated in the first request. 
    If not found: 
    3. Assume keys are stolen - series is destroyed 

Thuật toán này sẽ không hoạt động bình thường cho tất cả các nút mặc dù!

+0

Nếu yêu cầu đầu tiên không quay trở lại trình duyệt, không phải là id phiên không xác định cho các yêu cầu khác không? – Tor

+0

vâng, rất tiếc là bạn đã đúng :( Chúng tôi đã chuyển sang bộ nhớ cache trong bộ nhớ cho thẻ được nâng cấp (giữ khoảng 5 giây). – bluegaspode

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