2012-02-14 37 views
5

Tôi đang cố gắng thiết lập xác thực biểu mẫu trên nhiều máy chủ và tên miền phụ. Tôi có phím máy tĩnh thiết lập cho mỗi ứng dụng như vậy:Thiết lập xác thực biểu mẫu liên tục trên nhiều máy chủ và tên miền phụ

<system.web> 
    <machineKey validationKey="574...7A7" 
       decryptionKey="2C3...A0D" 
       validation="HMACSHA256" 
       decryption="AES" /> 
</system.web> 

... và hình thức xác thực của tôi được cấu hình giống nhau cho mỗi ứng dụng:

<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" /> 

Tôi cũng đã cố gắng đặt trước từ tên miền của tôi với một khoảng thời gian như tôi đã thấy một số người đề xuất, nhưng điều đó cũng không hiệu quả.

Tính năng này hoạt động tốt trên máy cục bộ của tôi với các trang web riêng được thiết lập trong IIS cho từng tên miền phụ. Nó cũng hoạt động tốt trên máy chủ dev của chúng tôi, nơi tất cả các trang web vẫn nằm trên một máy duy nhất. Tuy nhiên, khi triển khai vào môi trường dàn dựng của chúng tôi, xác thực miền chéo ngừng hoạt động. Trong môi trường đó, tôi có trang web chính (nơi đăng nhập xảy ra) đang chạy trên một máy chủ duy nhất và trang web phụ (nơi xác thực của tôi sẽ vẫn tồn tại) chạy trên hai máy chủ cân bằng tải. Tất cả đang chạy dưới IIS 7 trên Windows 7 (cục bộ) hoặc Server 2008 R2 (dev và dàn dựng).

Tôi đã xác minh rằng các phím máy giống nhau bằng cách mã hóa một chuỗi trên trang chính bằng MachineKey.Encode và giải mã kết quả trên máy chủ phụ với MachineKey.Decode. Tôi cũng đã xác minh rằng cookie .SHAREDAUTH được chuyển đến ứng dụng thứ hai trong yêu cầu , cả hai bằng cách kiểm tra các tiêu đề yêu cầu như được Firefox và Chrome báo cáo và gắn trình gỡ lỗi vào Application_BeginRequestApplication_AuthenticateRequest. Tôi có thể thấy cookie trong khi thực hiện Application_BeginRequest nhưng đã biến mất khi Application_AuthenticateRequest được gọi. Từ những gì tôi có thể thu thập, điều đó có nghĩa là việc deserialization của vé xác thực thất bại, nhưng tôi không thể hiểu tại sao điều đó có thể xảy ra trong môi trường multi-server, nhưng không phải là môi trường máy chủ đơn, ngoài các phím máy khác nhau , mà tôi đã xác nhận không phải là trường hợp.

Tôi cũng có thiết lập MembershipProvider và RoleProvider tùy chỉnh và những tác phẩm này hoạt động độc lập trên mỗi trang web.

Tôi đang thiếu gì?

+0

Hãy không tiền tố tiêu đề của bạn với "ASP.Net C# -" và như vậy. Đó là những gì các thẻ cho. –

+0

Đối với những người có cùng vấn đề, tôi thực hiện các mẹo trong bài đăng này: http://stackoverflow.com/questions/8361323/net-2-0-web-app-authentication-failing-the-ticket-supplied- không hợp lệ – user1482638

Trả lời

3

Vì vậy, sau một slog dài tôi phát hiện MS security bulletin MS11-100, bản vá lỗi độ cao đặc quyền dễ bị tổn thương trong xác thực biểu mẫu. Thật không may, bản vá không tương thích ngược. Nó được áp dụng cho các máy chủ cân bằng tải của chúng tôi, nhưng không cho máy chủ lưu trữ ứng dụng đã tạo đăng nhập ban đầu, điều đó có nghĩa là các máy chủ cân bằng không thể deserialize vé xác thực được viết bởi máy chủ ứng dụng.

Per the MS deployment guidance article, nếu bạn thấy mình trong tình huống này, bạn có thể thêm

<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" /> 

đến appSettings phần trong web.config cho các ứng dụng trên các máy với các bản vá được cài đặt (hoặc cấu hình máy cấp). Hoặc, tốt hơn hết, hãy chắc chắn bạn đang lưu trữ công ty quản lý áp dụng các miếng vá cho tất cả các máy chủ của bạn cùng một lúc ...

0

Đối với tôi nó hoạt động thêm phím này trong appSettings:

<add key="aspnet:UseLegacyEncryption" value="true" /> 
    <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" /> 
Các vấn đề liên quan