Tôi đang cố gắng tìm ra cách tốt nhất để thiết lập môi trường dàn dựng với một số hạn chế truy cập.

Giải pháp đơn giản là đưa ra Xác thực cơ bản, nhưng sau đó tôi sẽ không thể chỉ ra Thông tin chi tiết về tốc độ trang của Google trong khi thử nghiệm tối ưu hóa hiệu suất, cũng như các dịch vụ bên ngoài tương tự khác mà tôi muốn truy cập.

Có thể làm cho nó hoàn toàn công khai với robot.txt để ngăn nó hiển thị trong các công cụ tìm kiếm. Nhưng mối quan tâm của tôi là có nguy cơ xảy ra bất kỳ lỗi nào trong tệp robots.txt là khá cao và tôi không phải lo lắng về điều đó.

Nếu bạn không chặn các công cụ tìm kiếm (hoặc nếu một số bỏ qua nó), thì bạn sẽ nhận được khách hàng trực tiếp đặt hàng vào trang web dàn dựng của bạn, điều đó sẽ không làm họ hài lòng.

Hoặc thậm chí tệ hơn, nếu bạn vô tình triển khai robot.txt để sản xuất, bạn sẽ mất tất cả nước trái cây Google và một phần doanh số tốt.

Vì vậy, tùy chọn mà tôi thích là hạn chế địa chỉ IP đơn giản. Nhưng tôi muốn có thể thêm / xóa các hạn chế mà không phải khởi động lại Nginx, chỉ để giảm thiểu rủi ro trong khi thực hiện các thay đổi.

Vì vậy, tôi bắt đầu nghiêng về một mô-đun nhanh, khi được bật, sẽ xem xét các địa chỉ IP của nhà phát triển và chỉ cho phép truy cập vào trang web (phía trước và phụ trợ) nếu địa chỉ IP của người dùng (hoặc X_FORWARDED_FOR) khớp với nó.

Tự hỏi liệu điều này nghe có vẻ là một giải pháp hợp lý hay liệu có điều gì đơn giản hơn mà tôi đang thiếu.

CẬP NHẬT: Cho rằng robot.txt có thể được điều khiển thông qua một công tắc phụ trợ gốc và thông báo cửa hàng demo sẽ ngăn chặn mọi đơn đặt hàng hợp pháp của khách hàng và vì tôi thực sự không quan tâm đến việc truy cập công khai vào trang web dàn dựng, tôi thích giải pháp của Phil.

Nhưng đối với bất kỳ ai muốn hạn chế quyền truy cập vào trang web dàn dựng của họ, tôi nghĩ giải pháp của Kris là cách tốt nhất.

CẬP NHẬT 2: Không chắc chắn 100% các tùy chọn robot.txt phải làm gì trong Cấu hình hệ thống> Thiết kế> Đầu HTML, nhưng trong trường hợp của tôi - và từ một tìm kiếm ngắn, điều này có vẻ phổ biến - Tôi chỉ có một robot.txt phẳng tập tin văn bản tại chỗ đang được sử dụng, do đó tùy chọn cấu hình không được tôn trọng.

Vì vậy, bây giờ tôi sẽ sử dụng mô-đun bảo trì: https://github.com/aleron75/Webgriffe_Maintenance

Một vài gợi ý - một số được tích hợp sẵn!

- Hạn chế IP của nhà phát triển được tích hợp trong Cấu hình hệ thống> Nhà phát triển:

Điều này không hạn chế truy cập IP. Di chuyển cùng.

• Cá nhân hạn chế IP là khó khăn và tôi thích xử lý việc này tại tường lửa. Các bảng IP cũng là một ứng cử viên, như hạn chế htaccess hoặc thông qua $_SERVER['REMOTE_ADDR']trong tệp index.php.

• Cập nhật meta robot trên mỗi trang mặc định trong CMS thành NOINDEX / NOFOLLOW khi đang dàn dựng trong Cấu hình hệ thống> Thiết kế> Đầu HTML:

• Trong cùng một khu vực cấu hình, là khả năng hiển thị thông báo cửa hàng demo :

Phương tiện chính của chúng tôi để khóa (hầu hết) môi trường dàn dựng là xác thực BASIC. Nhưng chúng tôi cũng có các biện pháp phòng ngừa để ngăn chặn chúng bị phát hiện bởi các động cơ, chặn một liên kết hiển thị trên một trang web công cộng (điều này không bao giờ xảy ra) và cũng để ngăn chặn chúng bị Google lập chỉ mục.

Tôi đã thiết lập một quy tắc /etc/httpd/conf.d/robots.confvới các bí danh sau:

Alias /robots.txt /<path_to_public_html>/robots.txt
<Location /robots.txt>
  Satisfy any
</Location>

Bí danh định tuyến tất cả các yêu cầu đến vị trí robot.txt đến một tệp bị khóa. Điều này có nghĩa là không có vấn đề gì trong tệp robot.txt trong thư mục gốc của Magento, máy chủ sẽ luôn phục vụ các quy tắc sau:

User-agent: *
Disallow: /

Vị trí và đáp ứng bất kỳ cho phép tệp robot.txt được phục vụ cho bất kỳ ai bất kể xác thực do chúng tôi không có disallow from anyquy tắc chung.

Để xác thực mật khẩu, tôi đã thiết lập quy tắc để tôi có thể mở xác thực tạm thời trên một trang web bằng cách thêm Satisfy anyvào .htaccesstệp. Điều này là do chúng tôi chạy nhiều trang web giai đoạn trên cùng một máy chủ dàn nội bộ chuyên dụng. Nó cũng sẽ cho phép thiết lập allow fromcác quy tắc cùng vớiSatisfy any xóa xác thực mật khẩu cho các địa chỉ IP cụ thể trong khi duy trì nó cho mọi người khác (nếu tôi thực sự cần).

Lý do tôi không thích danh sách trắng dựa trên IP trên bảng (nghĩa là không có xác thực dựa trên mật khẩu) là vì địa chỉ IP của khách hàng không phải lúc nào cũng tĩnh. Điều đó có nghĩa là sau đó chúng tôi sẽ phải cập nhật IP của họ để có được quyền truy cập hàng ngày hoặc hàng tuần tùy thuộc vào thời gian DHCP ISP của họ giữ hợp đồng thuê.

Đối với DNS, chúng tôi sử dụng DNS ký tự đại diện để trình thu thập thông tin DNS sẽ không nhận được trên tất cả các tên máy chủ trang web giai đoạn cần có DNS công khai. Google thực sự sẽ chọn một trang web từ các bản ghi DNS. Điều này ngăn chặn điều đó, có nghĩa là cách duy nhất để họ tìm thấy nó là nếu ai đó để lại một liên kết nằm ở đâu đó. Nhưng với việc buộc tập tin robot phục vụ quy tắc không cho phép sẽ ngăn họ lập chỉ mục nếu họ tìm thấy một liên kết.

Khi tôi ở vị trí của một thương gia đang điều hành một trang web sân khấu cho trang web của công ty, tôi sẽ làm mọi thứ hơi khác một chút và sẽ chỉ chặn mọi lưu lượng truy cập đến hộp sân khấu trừ khi có địa chỉ IP được biết đến. Bất cứ ai làm việc trên trang web từ xa (trong nhà) sẽ được yêu cầu kết nối với VPN của công ty để truy cập nếu họ không có IP tĩnh mà tôi có thể đưa vào danh sách trắng.

Có DNS công cộng là điều bắt buộc nếu bạn cần kiểm tra những thứ như tích hợp bộ xử lý thanh toán, điều này, không giống như hầu hết các cổng, phải thực hiện cuộc gọi lại đến máy chủ để thực hiện quy trình thanh toán.

Tôi đã phát triển một mô-đun để cho phép chế độ bảo trì có thể được sử dụng với cùng tác dụng chặn người dùng truy cập vào mặt trước (không phải quản trị viên có thể bị giới hạn với tính năng chặn IP gốc của Magento).

Bạn có thể cho phép một số IP truy cập vào lối vào ngay cả khi bật chế độ bảo trì.

Có lẽ bạn có thể thử nó, hy vọng nó có thể giúp đỡ. Đó là nguồn mở và miễn phí: https://github.com/aleron75/Webgriffe_Maintenance

Có một số cách khác nhau để làm điều này.

Một cách sẽ là làm cho nhà phát triển của bạn chỉnh sửa tệp / máy chủ của họ với địa chỉ IP chính xác.

Có một tiện ích mở rộng ra rằng tuyên bố sẽ thực hiện việc này theo cách thanh lịch hơn: http : //www.magentoc Commerce.com/magento-connect/et-ip-security.html

Vì bạn đã hỏi về Varnish trong các nhận xét, tôi sẽ chia sẻ cấu hình của mình với Xác thực cơ bản HTTP bằng cách sử dụng Varnish, bao gồm các trường hợp ngoại lệ. Bạn phải thiết lập nó trong VCL, nếu không các trang được lưu trong bộ nhớ cache sẽ luôn có thể truy cập được.

Cấu hình VCL mờ

Tôi muốn cho phép một số địa chỉ IP và phạm vi nhất định cho các cuộc gọi lại của các nhà cung cấp thanh toán và như vậy, mà tôi xác định là ACL ở đầu tệp VCL:

acl payment {
  "1.2.3.4"/28;
  "1.3.3.7";
}

Sau đó thêm phần sau vào cuối vcl_recv, ngay trước return (lookup):

if (! req.http.Authorization ~ "Basic XXXXXXXXX"
&& ! client.ip ~ payment
&& ! req.url ~ "^/index.php/ADMIN/.*/upload") {
    error 401 "Restricted";
}

paymentlà ACL được định nghĩa ở trên. Tôi cũng cho phép truy cập vào tuyến tải lên vì trình tải lên Flash không gửi các tiêu đề xác thực và do đó không thành công sau HTTP Basic Auth. Thay thế ADMIN bằng URL quản trị viên thực tế của bạn. Bạn có thể thêm bất kỳ trường hợp ngoại lệ khác theo cách này.

XXXXXXXXX là tên người dùng và mật khẩu được mã hóa base64. Chạy phần sau trên shell để tạo chuỗi này:

$ echo -n "username:password" | base64

Sau đó thêm phần này vào cuối VCL để xác định phản hồi lỗi 401:

sub vcl_error {
if (obj.status == 401) {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  set obj.http.WWW-Authenticate = "Basic realm=Secured";
  synthetic {" 

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

 <HTML>
 <HEAD>
 <TITLE>Error</TITLE>
 <META HTTP-EQUIV='Content-Type' CONTENT='text/html;'>
 </HEAD>
 <BODY><H1>401 Unauthorized (varnish)</H1></BODY>
 </HTML>
 "};
  return (deliver);
}
}