2009-07-09 24 views
8

(Xem câu hỏi dưới đây để biết bối cảnh nhiều hơn):<machineKey decryptionKey = "AutoGenerate" ... bị bỏ qua bởi IIS. Sẽ không làm mất hiệu lực cookie phiên trước

Có bất kỳ tình huống trong đó

<machineKey 
     validationKey="AutoGenerate,IsolateApps" 
     decryptionKey="AutoGenerate,IsolateApps"/> 

trong web.config sẽ thất bại trong việc AutoGenerate một machineKey mới trên App Hồ bơi tái chế? Đây là hành vi tôi thấy ...


Tôi đang sử dụng ASP.NET FormsAuthentication chuẩn trong ứng dụng MVC. Nếu tôi đăng nhập người dùng bằng cách sử dụng FormsAuthentication.GetAuthCookie và không sử dụng cookie liên tục (dựa vào phiên của trình duyệt để nhớ trạng thái được ủy quyền của tôi), tôi sẽ mong tái chế IIS App Pool để vô hiệu hóa kiến ​​thức của phiên này cookie ... và do đó đăng xuất tất cả người dùng không có cookie liên tục. Điều này xảy ra trên một trong các cài đặt IIS của tôi (XP), nhưng trên một cấu hình IIS khác nhau (Server 2K3) Cookie FormsAuthentication (dưới tên chuẩn ".ASPXAUTH") vẫn hợp lệ và tiếp tục cho phép người dùng.

Có ai biết tại sao điều này đang xảy ra hay cấu hình nào kiểm soát hành vi này?

Rõ ràng là việc tái chế hồ bơi ứng dụng không kiểm soát được trình duyệt vẫn gửi cookie .ASPXAUTH (miễn là tôi chưa đóng trình duyệt và cookie chưa hết hạn).

Trong trường hợp của IIS cài đặt đúng cách từ chối chứng thực sau một thùng, tôi có thể nhìn thấy các tập tin cookie đến trong Request.Cookies trong sự kiện Application_BeginRequest ... nhưng một khi di chuyển để kiểm soát sự kiện tiếp theo có sẵn trong Global.asax.cs (Application_AuthenticateRequest), cookie đã bị xóa khỏi bộ sưu tập Request.Cookies.

Tại sao điều này không xảy ra đối với cả cấu hình IIS/ASP.NET?


Trong trường hợp này là không rõ ràng, một cách đơn giản hình thành câu hỏi là:

Tại sao HttpContext.Current.Request.Cookies[".ASPXAUTH"] thay đổi từ {System.Web.HttpCookie} null khi tôi bước, trong một yêu cầu duy nhất, Application_BeginRequest-Application_AuthenticateRequest? thông tin gỡ lỗi


thêm:

Nếu tôi đính kèm đoạn mã sau vào sự kiện FormsAuthentication_OnAuthenticate Global.asax.cs của ...

var cookie = Request.Cookies[FormsAuthentication.FormsCookieName]; 
if (cookie != null) 
{ 
    var val = cookie.Value; 
    try 
    { 
     FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val); 
    } 
    catch (Exception) 
    { 
    } 
} 

... sau đó trong một yêu cầu trước tôi tái chế IIS App Pool, không có ngoại lệ nào bị bắt. Sau khi tái chế IIS App Pool, khi cookie chính xác .ASPXAUTH được gửi từ trình duyệt, ngoại lệ mã hóa bị bắt ("Padding không hợp lệ và không thể bị xóa.")

Tại sao lại như vậy?

+1

Là một cấu hình để sử dụng ASP.NET State Service để lưu phiên thay vì inproc? – devstuff

+0

Ý nghĩ tốt - không, cả hai đều sử dụng InProc, thật không may. – kamens

Trả lời

-2

Cookie xác thực biểu mẫu không có liên quan gì đến trạng thái Phiên.

+0

1) Tái chế hồ bơi ứng dụng của bạn sẽ tái chế phiên của bạn (nếu bạn đang sử dụng quản lý phiên InProc), và điều này dường như * không * đôi khi thao tác cookie ASPXAUTH (như đã thấy khi nó bị xóa sau sự kiện BeginRequest). 2) Tôi sẽ làm cho câu hỏi của mình rõ ràng hơn bằng cách chỉ ra "phiên trình duyệt". Từ tài liệu MS: createPersistentCookie Loại: System.Boolean đúng để tạo cookie bền (một cookie được lưu trong các phiên trình duyệt); ngược lại, sai. – kamens

+0

Vô nghĩa. Cookie cư trú trên máy khách. Không có gì bạn có thể làm với máy chủ sẽ loại bỏ các cookie được lưu trữ trên máy khách. –

+0

Bạn sẽ nghĩ như vậy, phải không? Cookie không bị xóa khỏi máy chủ cho đến khi Application_BeginRequest kết thúc. Tôi biết điều này thật lố bịch, đó là lý do tại sao tôi đăng câu hỏi này. Tôi có một trình gỡ lỗi lên, và khi tôi bước từ Application_BeginRequest đến Application_AuthenticateRequest, giá trị của HttpContext.Current.Request.Cookies [". ASPXAUTH"] thay đổi từ {System.Web.HttpCookie} thành null. – kamens

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