Cookie phiên ASP.net bị mất hoặc bị xóa

Question

Tôi có trang web ASP.NET 2.0 lưu trữ ID của người dùng trong phiên để cho biết rằng họ đã đăng nhập. Trong một số trường hợp, người dùng dường như không đăng nhập được. đã theo dõi lưu lượng truy cập ở Fiddler và một số chi tiết tôi đã tìm thấy:

• Sự cố 100% có thể lặp lại trên máy tính xách tay cũ khi chạy IE7 và máy tính xách tay của người quản lý dự án khi chạy IE7. Vấn đề không bao giờ xảy ra trên máy tính xách tay hiện tại của tôi đang chạy IE7, hoặc bất kỳ máy tính xách tay nào khi chạy FF.
• Sự cố chỉ xảy ra trong sản xuất - không phát triển, dàn dựng nội bộ hoặc dàn dựng khách hàng. Sản xuất là môi trường cân bằng tải duy nhất, nhưng độ lặp lại được lưu ý ở trên làm cho tôi cân bằng tải câu hỏi như một yếu tố.
• Khi trang đặt Phiên ("ID") = 1 gửi phản hồi cho khách hàng, tôi có thể thấy tiêu đề "Đặt cookie" trong mọi trường hợp, tạo cookie ASP.Net_Session_Id (và đó là HttpOnly).
• Các yêu cầu tiếp theo đối với máy chủ sẽ gửi cookie đó trong tiêu đề trên các máy không hiển thị sự cố, nhưng không phải trên máy, hoặc cookie bị xóa hoặc tiêu đề "Đặt cookie" bị bỏ qua.
• Cách đăng nhập hoạt động như sau: một trang trên www.DomainX.com có ​​khung nội tuyến. Nguồn của iframe đó là một trang trên login.DomainY.com. Một loạt các trang được cung cấp từ login.DomainY.com đưa người dùng thông qua quá trình đăng nhập/đăng ký. Bước cuối cùng của login.DomainY.com là chuyển hướng đến một trang trở lại trên www.DomainX.com, bao gồm ID của người dùng trong chuỗi truy vấn. Trang này trên www.DomainX.com thường lưu trữ ID trong phiên và sau đó chạy một số JS để chuyển hướng tài liệu cấp cao nhất đến một trang mới, do đó đưa người dùng ra khỏi khung nội tuyến. Đây là một quá trình đã hoạt động trong nhiều năm, với một vài giá trị của DomainX.com. Một điều có thể khác ở đây là trong trường hợp này, JS đơn giản phá hủy iframe và một số chứa div.
• Một sự khác biệt tôi thấy giữa các tình huống xảy ra sự cố và vị trí không nằm trong cookie của Google Analytics. Có sự khác biệt khi login.DomainY.com/FinalStep.aspx thực hiện chuyển hướng của nó tới www.DomainX.com/SaveTheID.aspx bên trong khung nội tuyến. Khi sự cố không xảy ra, yêu cầu SaveTheID.aspx bao gồm nhiều cookie Google Analytics khác nhau (__utma, __utmz, v.v.). Khi sự cố xảy ra, yêu cầu này không bao gồm tất cả cookie GA (thiếu __utma, __utmz và __utmb).
• Sản xuất là môi trường duy nhất có đăng nhập.DomainY.com chạy dưới SSL, vì vậy tôi nghĩ rằng có thể có liên quan. Nhưng chúng tôi tạm thời thiết lập bản sao đăng nhập của chúng tôi.DomainY.com để sử dụng SSL và điều đó không có hiệu lực.

Bất kỳ ý tưởng nào có thể gây ra điều này?

Chỉnh sửa: môi trường sản xuất có các miền của www.DomainX.com và DomainX.com. Có một vấn đề khác đã biết với các cookie không được đặt cho cả hai tên miền đó. Có thể điều này là có liên quan, nhưng tôi sẽ không thể kiểm tra cho đến khi sửa chữa đó đi vào sản phẩm.

Answer 1

Bạn sẽ muốn xem nhà cung cấp trạng thái phiên để xem liệu nhà cung cấp có hoạt động trên hai máy chủ/phiên bản của ứng dụng .net hay không. Nếu chúng được thiết lập ví dụ để inProc thì bạn chắc chắn nhất sẽ chạy vào vấn đề này vì mỗi phiên sẽ được gắn với chủ đề mà nó được tạo ra. Thay vào đó, bạn muốn trừu tượng hóa dịch vụ trạng thái asp.net mà cả hai máy có thể truy cập hoặc thậm chí tốt hơn bạn nên sử dụng giải pháp bộ nhớ đệm phân tán như dự án Microsoft Velocity sẽ phân phối phiên trên hai máy trong trường hợp một máy bị hỏng.Một số cách khác để giải quyết vấn đề này là sử dụng các phiên dính trên bộ cân bằng tải (không khuyến nghị) hoặc chuyển sang phiên cookie ít hoạt động hơn nhưng có thể gây ra một số cơn đau đầu trong mã của bạn.

Trong doanh nghiệp của chúng tôi, chúng tôi có một máy chủ chính và phụ với bộ nhớ cache được phân phối phía sau để nếu một máy bị hỏng thì máy kia có thể tiếp quản. Nguyên tắc tương tự này áp dụng cho cân bằng tải và khi bạn bắt đầu có nhiều hơn một máy hoặc thậm chí nhiều hơn một cá thể trong nhóm ứng dụng, bạn sẽ phải viết mã cho điều này.

Nếu bạn sử dụng Tốc độ cho phiên, hãy đảm bảo rằng bộ nhớ cache bạn chọn để lưu trữ phiên của mình không thể gỡ bỏ được.

Answer 2

Tôi nghĩ Middletone là đúng ngoại trừ: nó không giải thích tại sao vấn đề không thể được repro'd với Firefox. Cân bằng tải là nghi can số 1; nó sẽ là tốt để xem nếu nó có một bằng chứng bằng cách lấy tất cả, nhưng một trong những máy chủ ứng dụng offline (nếu khả thi, và trong một thời gian khi nó có thể xử lý tải) và xem nếu vấn đề vẫn còn tồn tại. Nếu vậy, nó không phải là cân bằng tải và bạn có thể bắt đầu tìm kiếm ở một nơi khác. Nếu không, đó là cân bằng tải.

BTW: Các phiên cố định không tốt vì các phiên trên đó không được bảo vệ bởi dự phòng. Ngoài ra, bộ cân bằng tải không thể phân phối tới máy chủ được tải ít nhất tại một thời điểm nhất định, nó chỉ có thể quyết định ở đầu phiên và sau đó giữ người dùng ở vị trí đó.

Nếu hóa ra bạn gặp vấn đề về cân bằng tải ở đây, điều đầu tiên tôi làm là bật tính dính của phiên, và sau đó có thể tìm giải pháp khác với backgroung nhẹ nhàng của môi trường sản xuất đang hoạt động.

Answer 3

bắn, tôi phải mất cookie và khả năng để trả lời và chỉnh sửa của tôi ...

tôi đã khám phá những cân bằng tải như vấn đề này một chút bằng cách sửa đổi file host của tôi chỉ trực tiếp đến các IP của mỗi của các máy chủ web và điều đó không có hiệu lực. Tôi nghĩ nhân viên CNTT của khách hàng sẽ phải chịu trách nhiệm khi yêu cầu tắt cân bằng tải.

Chúng tôi có một máy chủ trạng thái riêng đang chạy và nó giống với máy chủ được sử dụng trong vài năm trên các trang web khác được lưu trữ bởi cùng một máy chủ. Không nhất thiết không có vấn đề, nhưng không có vấn đề như thế này.

Là một nhóm hỗ trợ, hiện tôi đang thử nghiệm các cơ chế bảo trì khác ...