Tôi biết điều này có cơ hội lớn được đánh dấu là trùng lặp, nhưng không thể tìm thấy chính xác những gì tôi đang tìm kiếm

Đây là một vấn đề phổ biến và tôi chắc chắn rằng nó có một số giải pháp thực hành tốt nhất được xác định rõ

Lý lịch

1. Một ứng dụng SaaS một trang, có nhiều thao tác kéo và thả, người dùng có thể tương tác với nó mà không cần giao tiếp nhiều máy chủ trong khoảng thời gian

2. Phiên máy chủ chỉ giữ đối tượng người dùng, sử dụng cookie phiên không liên tục

3. Phiên hết hạn trên máy chủ sau X giờ

4. Một số thứ chỉ được tải trong khi đăng nhập

Vấn đề

1. Người dùng hoạt động trên ứng dụng, khi hoàn tất, người dùng không đăng xuất, chỉ cần mở trình duyệt
2. Người dùng quay lại sau hơn X giờ (phiên không hợp lệ trên máy chủ)
3. Người dùng tương tác với ứng dụng mà không cần kết nối máy chủ (kéo và thả đồ, chỉnh sửa văn bản ...)
4. Chỉ trên tương tác máy chủ tiếp theo (giả sử không có lưu tự động), người dùng sẽ bị ném vào trang đăng nhập và mất một số công việc của họ

Phương pháp khả thi

Dưới đây là một số giải pháp tôi có trong đầu, muốn nghe nếu có bất kỳ giải pháp nào khác, và nếu có bất kỳ điều gì sai về cơ bản với bất kỳ trong số họ.

1. Không bao giờ đăng xuất người dùng

• Làm sao? hoặc giữ một phiên dài, giữ một cookie liên tục hoặc javaScript "giữ mạng"
• Ưu điểm : người dùng không cần phải lo lắng về bất cứ điều gì, khắc phục sự cố cho họ
• Nhược điểm : không tuân thủ PCI, không bảo mật và cần thay đổi phát triển, ví dụ: những thứ được tải đến phiên chỉ khi đăng nhập người dùng cần chuyển sang mô hình phụ pub (nghe thay đổi sự kiện) hoặc hết thời gian chờ bộ đệm.

2. Lưu trữ cục bộ

• Làm sao? sử dụng bộ nhớ cục bộ mới để tạm thời lưu trữ trạng thái nếu đăng xuất, chuyển hướng đến trang đăng nhập, tiếp tục đăng nhập
• Ưu điểm : Cũng dựa trên cơ sở hỗ trợ "làm việc ngoại tuyến", không chỉ xử lý thời gian chờ phiên
• Nhược điểm : khó thực hiện hơn, cần thực hiện hợp nhất trạng thái cây dữ liệu, không phải tất cả các trình duyệt đều hỗ trợ

3. Tự động lưu

Mọi hành động của người dùng thay đổi mô hình, sẽ tồn tại ngay lập tức (hoặc thông qua một số loại hàng đợi phía máy khách), ví dụ: nếu họ kiểm tra hộp kiểm, thay đổi trường văn bản hoặc kéo và thả một cái gì đó, sau khi hoàn thành, vẫn tiếp tục thay đổi.

• Làm sao? Sử dụng khung MV ** (Backbone.js / Knockout.js / Ember.js / Angular.js, v.v.) để liên kết mô hình và kiên trì thay đổi.
• Ưu điểm : Có vẻ như là một giải pháp sạch, phiên hoạt động miễn là người dùng hoạt động, không có công việc phía khách hàng nào được thực hiện mà không cần duy trì.
• Nhược điểm : Người dùng hành động cuối cùng đang thực hiện sau khi hết thời gian phiên.

4. Đăng xuất người dùng sau khi hết hạn phiên

điều này có thể có một số cách tiếp cận

1. Hỏi máy chủ "đã hết phiên" - đây là một chút của con mèo 22 / Schrodinger, vì câu hỏi đơn thuần cho máy chủ mở rộng phiên (khởi động lại thời gian chờ),

   • Làm sao? Hoặc có một máy chủ hỗ trợ câu hỏi như vậy (tôi không biết, nhưng tôi đến từ vùng đất Java) hoặc, người ta chỉ có thể giữ một bảng ID phiên và thời gian truy cập lần cuối theo cách thủ công và hỏi máy chủ bằng cách vượt qua phiên ID là một tham số thay vì cookie, tôi không chắc liệu điều này có khả thi hay không, nhưng nó có vẻ nguy hiểm, không an toàn và thiết kế xấu trang whatsoever.login, vẫn tồn tại sau khi đăng nhập
   • Ưu điểm : Nếu có hỗ trợ riêng như vậy trong các máy chủ, nghe có vẻ là một câu hỏi rõ ràng, hợp pháp (hỏi xem người dùng X có còn phiên hay không mà không gia hạn nếu họ làm như vậy)
   • Nhược điểm : Nếu máy chủ không hỗ trợ nó (và một lần nữa, tôi không biết liệu có máy chủ hoặc khung nào có chức năng này không) thì cách giải quyết có nguy cơ bảo mật rất lớn.

2. Một cách giải quyết mà tôi đã nghe là có một phiên ngắn ở phía máy chủ và ping máy khách vẫn còn sống, có số lần ping tối đa

   • Làm sao? Phiên ngắn trên máy chủ, máy khách ping mỗi sessionTimeOut / 2, có số lần thử lại tối đa là Y.
   • Ưu điểm : Loại sửa lỗi, nhanh và bẩn
   • Nhược điểm : Cảm thấy giống như hack, tự xử lý việc gia hạn phiên thay vì để máy chủ thực hiện

3. Hẹn giờ phía khách hàng

   • Làm sao? Có một bộ đếm thời gian ở phía máy khách và đồng bộ hóa nó với máy chủ bằng cách khởi động lại nó trên mỗi yêu cầu bằng với thời gian chờ phiên máy chủ tối đa trừ một số phần đệm, sau khi người dùng không gửi bất kỳ yêu cầu nào đến máy chủ, UI hiển thị "phiên là sắp hết giờ, bạn có muốn tiếp tục không? " (giống như bạn có trên ngân hàng trực tuyến)

   • Ưu điểm : Khắc phục sự cố

   • Nhược điểm : Không thể nghĩ ra bất kỳ thứ gì ngoại trừ nhu cầu đảm bảo đồng bộ hóa hoạt động

Câu hỏi

Tôi có thể thiếu một cái gì đó trong phân tích ở trên, có thể có một số sai lầm ngớ ngẩn, và tôi muốn bạn giúp đỡ để sửa chúng. Tôi có thể có giải pháp nào khác cho việc này?

Tôi nghĩ rằng giải pháp đơn giản phổ biến nhất là bạn đặt bộ hẹn giờ ở đầu máy khách hiển thị thông báo sau khi một phần nhất định của cửa sổ hết thời gian bình thường trôi qua sau đó buộc phải đăng xuất chúng ngay trước khi phiên hết hạn nếu chúng không có hành động.

Lưu trữ cục bộ và tự động lưu giới thiệu một số vấn đề với các giao dịch và những gì thực sự có nghĩa là lưu. Tôi đã tham gia vào một vài dự án mà điều này trở nên rắc rối hơn so với giá trị khi cơ sở người dùng không hiểu các cơ chế đằng sau nó.

Không bao giờ đăng xuất có thể được thực hiện khi quy định cho phép, nhưng nó dẫn bạn đến những sai lầm khi bạn không xử lý chính xác những gì xảy ra nếu ai đó đăng xuất bất ngờ và tất cả các hoạt động kinh doanh của nhà nước trở nên hơi khó khăn để duy trì nếu có nhiều việc phải theo dõi một người dùng "hoạt động".

Một cách giải quyết mà tôi đã nghe là có một phiên ngắn ở phía máy chủ và ping phía máy khách còn sống, có số lượng tối đa là

Làm sao? Phiên ngắn trên máy chủ, máy khách ping mỗi phiên Thời gian / 2, có tối đa> thử lại Y. Ưu điểm: Loại sửa lỗi, nhanh và bẩn Nhược điểm: Cảm thấy như hack, tự xử lý việc gia hạn phiên thay vì> để máy chủ thực hiện

Đây là ý kiến ​​của tôi giải pháp tốt nhất. Tại sao bạn coi nó là một "hack bẩn"?

Nó làm chính xác những gì phải được thực hiện. Trong khi người dùng làm việc với chương trình, phiên sẽ vẫn mở.

Sau khi người dùng dừng hoạt động với chương trình, phiên sẽ được đóng lại.

Đủ đơn giản để thực hiện

Chính xác những gì cần thiết, nếu tôi hiểu đúng câu hỏi.

Tôi thực sự đang tạo ra một ứng dụng liên quan đến việc này.

Tôi bắt đầu bằng cách tạo ra một dịch vụ RESTful bằng Django, Guradian và Tastypie. Nó xác thực chỉ sử dụng APIKEY, ủy quyền cho các đối tượng được xử lý bởi Guardian.

Ứng dụng django chỉ có một urlcs xem mẫu tải tải cơ sở.html đó là ...

Về phía khách hàng, tôi đã tạo một ứng dụng bằng Angular.

Theo như xác thực, có một http-auth-đánh chặn lắng nghe 401 phản hồi.

Khi nhận được một 401, nó sẽ đệm yêu cầu gửi đi và thực hiện một sự kiện "yêu cầu đăng nhập". Điều này có thể xảy ra nhiều lần.

Tôi có một cửa sổ bật lên phương thức có chứa một biểu mẫu đăng nhập được trình bày khi nghe thấy sự kiện "yêu cầu đăng nhập" và nó thực hiện đăng nhập trả về tài nguyên Người dùng (gói JSON) cũng chứa APIKEY.

Tất cả các yêu cầu được đệm trước đây dẫn đến phản hồi 401 được phát lại với APIKEY giờ được bao gồm trong tiêu đề http ủy quyền.

Tôi sử dụng một dịch vụ / nhà máy góc cạnh khác để quản lý dữ liệu cục bộ cục bộ và đó là nơi tôi lưu trữ tên người dùng và apikey.

Phần duy nhất của câu đố còn lại để giải quyết là làm thế nào để bảo mật thông tin đó và cách thực thi thời gian chờ đối với thông tin đó.

Có lẽ sử dụng kiểm tra dấu thời gian từ yêu cầu http hợp lệ cuối cùng.

Trong trường hợp của tôi, tôi đang sử dụng một cái gì đó tương tự như 4.1. Sau khi người dùng đăng nhập vào một yêu cầu AJAX json điều khiển góc rất nhẹ xảy ra với API REST theo các khoảng thời gian được đặt trước máy chủ. Do các yêu cầu bảo mật, giao diện người dùng độc quyền dự đoán máy chủ sẽ duy trì phiên cho người dùng lưu trữ một số thông tin, mẫu, dữ liệu được bảo vệ ở phía máy chủ. Đây vẫn là phương pháp ưa thích của tôi từ góc độ bảo mật. Khi xử lý dữ liệu nhạy cảm (không chỉ là mật khẩu băm và như vậy), IMO lưu trữ phía máy khách trong Local Storage, v.v ... có rủi ro lớn hơn phía máy chủ (tôi chắc chắn ai đó sẽ tranh luận điều đó với tôi). Các bên thứ ba sử dụng cùng một API khi liên lạc với hệ thống, nhưng phải gửi thông tin xác thực cho mỗi yêu cầu.

Phiên trên máy chủ có thời gian nhàn rỗi tối đa được áp dụng cho nó và công cụ lưu trữ phiên được ghi nhớ (cũng có thời gian tồn tại tối đa được áp dụng tại thời điểm mà phiên bộ nhớ sẽ được đánh dấu hết hạn). Nhu cầu trọn đời chỉ lớn hơn bất kỳ phiên nào mà bạn trừu tượng trong ứng dụng của mình (và không phải là nhiều của tôi). EG Phiên có thể không hết hạn cho đến khi không hoạt động trong 48 giờ khi máy chủ có liên quan, nhưng mã của bạn kiểm soát thời gian thực tế. Điều này có thể dẫn đến các vấn đề về tài nguyên nếu thời gian đó quá lớn và bạn làm việc kém trong việc quản lý các phiên.

Trong trường hợp của tôi, những người dùng khác nhau có thể có thời gian chờ phiên khác nhau dựa trên vai trò của họ trong tổ chức. Máy chủ đặt giới hạn tối đa cho thời gian tồn tại của phiên nhưng miễn là giới hạn do người dùng xác định ít hơn giới hạn, nó hoạt động tốt. Khi máy chủ hết hạn phiên, đó là một vấn đề cần thiết vì quá trình hết hạn phiên sẽ được ứng dụng xử lý một cách duyên dáng. Đây là một yêu cầu của loại ứng dụng kinh doanh tôi đã xây dựng.

Khi phiên người dùng không hoạt động và nằm trong ngưỡng được chỉ định của ứng dụng, API sẽ hướng dẫn UI hiển thị hộp thoại đếm ngược (giống như các ngân hàng thực hiện) và một khi nó nằm trong một khoảng cách cụ thể theo thời gian kể từ khi hết hạn một cách duyên dáng đăng xuất người dùng. Chức năng này vẫn tồn tại trên các cửa sổ trình duyệt (vì máy chủ đang kiểm soát) và một sự kiện nhàn rỗi trên bất kỳ cửa sổ nào sẽ bắt đầu bộ đếm thời gian duyên dáng và quá trình đăng xuất tự động (và giữ chúng đồng bộ hóa).

Nếu tình cờ phiên hết hạn một cách thiếu trung thực (các phiên bị hủy trên memcached), yêu cầu tiếp theo tác động đến máy chủ sẽ thông báo cho người dùng và chuyển chúng trở lại hình vuông (hiếm khi xảy ra, nhưng có thể).