2009-05-04 4 views
5

Giả sử bạn đang viết một ứng dụng WinForms dựa trên mạng được cho là chạy trong một môi trường "hoang tưởng" do các chính sách hạn chế của công ty tại trang web của khách hàng. Môi trường thù địch như vậy có những loại hạn chế nào, và bạn đã làm gì để thiết kế chúng?Môi trường công ty thù địch nhất để triển khai ứng dụng .NET WinForms là gì?

Một số ví dụ để bắt đầu với:

  • Vấn đề: Có một bức tường lửa rất hạn chế chỉ cho phép cổng outbound 80 giao thông. Giải pháp: chỉ sử dụng HTTP để thực hiện kết nối mạng của bạn.
  • Vấn đề: Khuôn khổ .NET không được phép. Giải pháp: biến ứng dụng của bạn thành ứng dụng web.

Một số hạn chế như vậy mà bạn gặp phải trong các tình huống thực tế của khách hàng, chẳng hạn như ví dụ trong phần mềm ngân hàng (thường cần phải sống trong một môi trường đặc biệt nghiêm ngặt)?

+2

Không phải điều này thực sự trả lời câu hỏi của bạn, nhưng nó nhắc tôi (đặc biệt là vấn đề đầu tiên) của RFC 3093. Tại một thời điểm nhất định, bạn phải thừa nhận rằng những hacks này có nghĩa là trốn tránh quản lý, không duy trì an ninh thực sự. –

+0

Đó là một loại bummer này được đóng lại, tôi nghĩ rằng nó sẽ có một câu hỏi wiki cộng đồng tốt. – overslacked

Trả lời

3

Vâng, phần đầu tiên của câu hỏi, tôi không chắc chắn. Tuy nhiên, với điểm bullet của bạn. Bạn có thể chạy máy chủ của mình trên cổng 80 và KHÔNG sử dụng HTTP nhưng giao thức tùy chỉnh của bạn. Bổ sung, chắc chắn tường lửa cho phép SSL (443), bạn có thể gói giao thức của bạn trong SSL là tốt. Theo như khuôn khổ .NET không được cho phép, bạn có thể sử dụng PostBuild của Xenocode hoặc loại ứng dụng "liên kết tĩnh" tương tự cho .NET. Ngoài ra, đối với nội dung HTTP, bạn có thể làm cho ứng dụng của bạn giao tiếp qua HTTP nhưng sử dụng Dịch vụ web và do đó vẫn cung cấp cho khách hàng phong phú.

Dưới đây là một liên kết đến PostBuild:

https://secure.xenocode.com/Products/Postbuild-for-NET/

+1

Có 443 mở theo cách mà một ứng dụng nội bộ có thể truy cập không được đảm bảo. Từ kinh nghiệm của tôi, trong hầu hết môi trường "chỉ cổng 80 đang mở", thực tế có một số proxy lọc được đặt ra - proxy này sẽ chỉ cho phép lưu lượng HTTP, thường loại bỏ tiêu đề mà nó không thích và sẽ âm thầm thay thế dữ liệu trả về HTTP nếu có vẻ như đã vi phạm các quy tắc của nó. – David

0

Bị buộc phải phát triển trong khuôn khổ cũ như .NET 1.1, 3 năm sau khi phát hành NET 2.0. Ngoài ra, ngắt kết nối giữa các nhóm máy tính để bàn và máy chủ. Nhóm máy tính để bàn nghĩ rằng .NET là xấu và không an toàn, trong khi nhóm máy chủ có phản ứng ngược lại chính xác và yêu thích .NET bởi vì nó có khả năng khóa môi trường với các quyền tin cậy.

Bạn không thể làm gì để thay đổi chính sách của công ty rất nhanh. Đó là một quá trình chậm, rất chậm để khiến họ chấp nhận điều gì đó mới mẻ.

1

Buộc tất cả lưu lượng truy cập mạng qua cổng 80 là tốt nhất. Và sau đó yêu cầu một redirector trên cổng 80 để cho phép nhiều ứng dụng máy chủ để "lắng nghe" trên một cổng vì mở bất kỳ cổng khác sẽ là một "nguy cơ bảo mật".

1

Có lẽ vấn đề lớn nhất bạn sẽ tìm thấy là các công ty không thường xuyên chạy Windows Update và không có quyền truy cập internet vào máy tính của họ. Khách hàng của tôi là như vậy, nhưng sau đó họ cần phải được.

Điều này có nghĩa là khi bạn triển khai phần mềm của mình, bạn cần biết nền tảng .net của họ và nói với họ rằng 'cập nhật lên phiên bản mới nhất' không phải lúc nào cũng là một tùy chọn. Đó là một nỗi đau thực sự để có được các bản cập nhật cài đặt mà không có internet, trên mỗi máy tính để bàn, và nhận được tất cả các phiên bản .net, gói dịch vụ và các bản vá lỗi MS lăn ra. Vì vậy, nếu bạn cung cấp mã yêu cầu một cái gì đó người dùng không có, bạn có thể phải viết lại nó.

2

Các công ty yêu cầu gắn bó với IE6. Điều đó có thể thêm toàn bộ chi phí nếu bạn cố gắng giải quyết các hạn chế với ứng dụng web.

Không cấp cho người dùng quyền quản trị cài đặt nội dung trên máy của họ cũng là một vấn đề lớn, vì có thể là một số cài đặt bảo mật trên trình duyệt mà họ có thể nhấn mạnh.