2010-10-15 39 views
5

Tôi đã thu thập tóm tắt (hy vọng hữu ích) về các cách tôi đã nghiên cứu để hoàn thành chủ đề của bài đăng này, cũng như các vấn đề tôi gặp phải với chúng. Xin vui lòng cho tôi biết nếu bạn đã tìm thấy những cách khác bạn thích tốt hơn, đặc biệt là nếu họ giải quyết các vấn đề mà các phương pháp tôi đề cập đến không.Triển khai chuỗi kết nối ASP.NET thực hành tốt nhất

  1. Để lại chuỗi kết nối trong web.config và sử dụng XDT/msdeploy chuyển đổi để thay thế chúng bằng cài đặt theo cấu hình hoạt động của tôi (ví dụ: tệp web.PublicTest.config). Vấn đề của tôi với điều này là tôi hợp nhất và chôn một vài thiết lập máy chủ cụ thể vào một tập tin giống hệt trên toàn cầu với nhiều yếu tố cấu hình. Ngoài ra, tôi không thể chia sẻ các định nghĩa chuỗi kết nối giữa nhiều ứng dụng ngang hàng.

  2. Chỉ định giá trị configSource = "DeveloperLocalConnectionStrings.config" cho chuỗi kết nối trong web.config và XDT biến đổi giá trị này để trỏ đến một trong nhiều tệp môi trường cụ thể trong mã cơ sở của tôi. Vấn đề của tôi với điều này là tôi gửi mật khẩu cho tất cả các môi trường của mình tới tất cả các đích (ngoài SVN, tất nhiên) và có các phần cấu hình chưa sử dụng đang ngồi trên các máy chủ đang chờ để vô tình sử dụng.

  3. Chuỗi kết nối cụ thể trong tệp machine.config chứ không phải là web.config. Vấn đề: ai heck hy vọng sẽ tìm thấy các chuỗi kết nối trong machine.config, và xác suất của các va chạm tên bất ngờ là kết quả cao.

  4. Chỉ định configSource = "LocalConnectionStrings.config", không chuyển đổi giá trị và chỉnh sửa dự án xml để loại trừ triển khai cấu hình chuỗi kết nối. http://msdn.microsoft.com/en-us/library/ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - Đó là giải pháp tốt nhất tôi đã tìm thấy để đáp ứng nhu cầu của mình cho một ứng dụng web độc quyền (không phân tán), nhưng tôi hoang tưởng một thành viên khác trong nhóm sẽ đến một ngày và sao chép trang web sản xuất để kiểm tra vì một lý do nào đó và ! Cơ sở dữ liệu sản xuất hiện đang được sửa đổi trong UAT. (Cập nhật: Tôi đã tìm thấy tôi không thể sử dụng một cú nhấp chuột xuất bản trong kịch bản này, chỉ msdeploy dòng lệnh với tham số -skip. Loại trừ một tập tin như trên là giống như thiết lập nó để "Không" biên dịch hành động thay vì " Nội dung "và kết quả trong gói xóa nó khỏi mục tiêu triển khai.)

  5. Dây gói triển khai lên để nhắc chuỗi kết nối nếu chưa được đặt (tôi chưa biết cách thực hiện điều này nhưng tôi hiểu điều đó là có thể). Điều này sẽ có kết quả tương tự như # 4 ở trên.

  6. Chỉ định configSource = ".. \ ConnectionStrings.config". Sẽ là tuyệt vời cho nhu cầu của tôi, vì tôi có thể chia sẻ cấu hình giữa các ứng dụng tôi chọn và sẽ không có máy cụ thể trong thư mục ứng dụng của tôi. Thật không may là đường dẫn cha mẹ không được phép trong thuộc tính này (giống như chúng dành cho 'appSettings file = ""' - cũng lưu ý rằng bạn có thể sử dụng tệp spiffily = bên trong một tham chiếu configSource =).

p.s. một số giải pháp được thảo luận tại đây: ASP.Net configuration file -> Connection strings for multiple developers and deployment servers

Trả lời

1
  1. Sử dụng tên máy chủ làm khóa cho chuỗi kết nối, theo cách đó bạn có thể chọn nguồn dữ liệu tự động. Hãy chắc chắn rằng thói quen chọn không phải là lỗi (thay đổi tên máy chủ - thử nghiệm!) ...

  2. Không đặt nó trong web.config, viết một tệp ini, theo cách đó không có mã hóa XML.

  3. Mã hóa mật khẩu trong đó bằng khóa riêng/khóa công cộng (RSA/PGP). Không bao giờ sử dụng văn bản rõ ràng, hoặc một khóa đối xứng, mà chỉ là xấu.

+0

1. Tôi thích nó - tuy nhiên, bạn sẽ cười, nhưng hiện thử nghiệm và ứng dụng dev hồ chạy trên máy chủ IIS cùng. – Shannon

+0

2. bạn có thể làm rõ không? tệp ini này có thể được sử dụng từ cùng một phương thức thư viện không? cụ thể, tôi có một chuỗi kết nối định dạng khung thực thể. – Shannon

+0

3. Cảm ơn bạn, tôi đã không nhận thức được tôi có thể sử dụng một phím bất đối xứng trong một chuỗi kết nối hoặc để mã hóa một chuỗi kết nối (tùy theo ý bạn). Tôi sẽ nghiên cứu để tìm hiểu thêm về cách thực hiện. – Shannon

0

Kiểm tra bài blog sau đây của tôi: Protecting asp.net machine keys and connection strings

Nếu bạn sử dụng câu trả lời tình thế khó khăn của, sử dụng một chìa khóa mà không có trong thư mục của trang web, giống như asp.net làm với phần cấu hình được bảo vệ.

Chúng tôi tự phê duyệt các thay đổi đối với web.config đi vào dàn dựng/sản xuất. Chúng tôi sử dụng tích hợp thay vì tên người dùng dựa vào nơi có thể, nhưng một tùy chọn mà chúng tôi đã sử dụng trong trường hợp sau là chỉ có phần giữ chỗ cho tên người dùng/mật khẩu trong SVN.

Chúng tôi đã sử dụng các tệp cấu hình riêng trong quá khứ, nhưng chúng tôi đã gặp phải các loại sự cố khác với sửa đổi web.config, vì vậy chúng tôi đã khóa nó trong một tệp gần đây.

+0

Cảm ơn Eglasius. Tôi thích ý tưởng về bảo mật tích hợp. Nó từng là MO của tôi, tôi không nhớ tại sao tôi lại dừng lại. Như chúng ta đã trải nghiệm, mọi điểm tương tác của con người là thời gian chết chờ đợi để xảy ra. – Shannon

3

Khi sử dụng SQL Server, bạn cũng có thể sử dụng Integrated Security/SSPI và thêm Đăng nhập máy tính WebServer vào Sql Server.

Bằng cách đó bạn không phải để lộ bất kỳ thứ gì trong web.config và bạn có thể cấp vai trò cho thông tin đăng nhập đó giống như bạn cho bất kỳ người dùng DB nào khác.

Mặc dù bạn phải hiểu các hàm ý và cân nhắc bảo mật cần thực hiện, vì bất kỳ mã độc nào được thực thi như máy THAT sẽ có quyền truy cập vào Sql Server.

liên quan Ole

+0

Tuyệt vời, cảm ơn Ole. Eglasius đã đề cập "tích hợp" một thời gian ngắn, nhưng không đề cập đến việc thêm thông tin đăng nhập. Lưu ý rằng có các hạn chế đối với các máy chủ không chia sẻ tên miền. Bạn có thể lưu một mật khẩu máy chủ từ xa, nhưng điều đó không thể được sử dụng cho các cột kiểu dòng MSSQL và cũng có các hạn chế khác. – Shannon

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