WordPress đằng sau proxy ngược Apache

Có một trường hợp sử dụng phổ biến cho blog Wordpress, nơi nó nằm “bên trong” trang web của bạn trong một thư mục con. www. ví dụ. com/blog. Với các ứng dụng máy chủ truyền thống, điều này cực kỳ dễ cấu hình. Chỉ cần cài đặt Wordpress tại vị trí thư mục con. Điều gì sẽ xảy ra nếu máy chủ web của bạn không có trạng thái và tận dụng các công nghệ như docker?

Đây là mục tiêu. làm cho một blog xuất hiện “bên trong” của một ứng dụng web sử dụng docker tại vị trí /blog

Những gì bạn sẽ cần

  1. Máy chủ web Apache / Nginx
    Tôi đang sử dụng Apache nhưng nó đủ dễ để thích ứng với Nginx.
  2. Wordpress Blog chạy trên bất kỳ tên miền / tên miền phụ nào
    Bạn có thể chạy nó trên WPEngine (tôi đã làm như vậy), lưu ý. WPEngine không đề xuất hoặc cung cấp hỗ trợ kỹ thuật cho các cấu hình ReverseProxy.
  3. Quyền truy cập Cơ sở dữ liệu Wordpress
    WPEngine cung cấp quyền truy cập phpMyAdmin
  4. Quyền truy cập ghi vào tệp Wordpress
    WPEngine cung cấp quyền truy cập SFTP để cho phép chỉnh sửa tệp.

Làm thôi nào. chúng tôi có một trang web tại https. //www. ví dụ. com và muốn blog xuất hiện tại https. //www. ví dụ. com/blog nhưng hiện tại nó đang chạy ở http. //một sốblog. miền nào đó. com

Bật mô-đun proxy cho máy chủ của bạn
Nếu bạn đang thực hiện việc này trên máy chủ, bạn sẽ phải chạy mô-đun này ở chế độ siêu người dùng và rất có thể sẽ phải khởi động lại máy chủ của mình.

a2enmod proxy proxy_http ssl

Tôi đã làm điều này trong docker nên tôi đã thêm lệnh vào Dockerfile của mình

Định cấu hình Apache / Nginx ProxyPass & ProxyPassReverse
Sửa đổi tệp cấu hình máy chủ web của bạn để bao gồm ProxyRequests, ProxyPass và ProxyPassReverse.

    DocumentRoot /var/www/app/public
SSLProxyEngine On

ProxyRequests off
ProxyPass /blog http://someblog.somedomain.com
ProxyPassReverse /blog http://someblog.somedomain.com

Chỉnh sửa tệp cấu hình WordPress
thêm đoạn mã sau vào gần cuối tệp wp-config.php.

# ProxyPass Settings 
#
# DO NOT REMOVE: overriding the following variables is
# required to ensure that any request /blog/* is handled
$_SERVER[‘REQUEST_URI’] = ‘/blog’ . $_SERVER[‘REQUEST_URI’];
$_SERVER[‘SCRIPT_NAME’] = ‘/blog’ . $_SERVER[‘SCRIPT_NAME’];
$_SERVER[‘PHP_SELF’] = ‘/blog’ . $_SERVER[‘PHP_SELF’];

Điều này sẽ ngăn Wordpress chuyển hướng bạn đang sử dụng các url lồng nhau cho các liên kết vĩnh viễn

Cập nhật ngày 13 tháng 7 năm 2021. Bạn cũng có thể thấy các câu lệnh

    DocumentRoot /var/www/app/public
SSLProxyEngine On

ProxyRequests off
ProxyPass /blog http://someblog.somedomain.com
ProxyPassReverse /blog http://someblog.somedomain.com
0 cho
    DocumentRoot /var/www/app/public
SSLProxyEngine On

ProxyRequests off
ProxyPass /blog http://someblog.somedomain.com
ProxyPassReverse /blog http://someblog.somedomain.com
1 và
    DocumentRoot /var/www/app/public
SSLProxyEngine On

ProxyRequests off
ProxyPass /blog http://someblog.somedomain.com
ProxyPassReverse /blog http://someblog.somedomain.com
2Nếu bạn thấy chúng, hãy nhớ cập nhật cả định nghĩa cho URL mong muốn của bạn

WordPress, đặc biệt là trong phiên bản 5+, là một phần mềm tuyệt vời. Tuy nhiên, trong một số trường hợp, mã mặc định bị thiếu. Gần đây, tôi cần thiết lập WordPress đằng sau một proxy ngược, lưu trữ song song một máy chủ dàn dựng và sử dụng cả trình tạo trang trực quan và plugin dịch thuật dựa trên javascript

Và tất cả những thứ đó cần phải dễ sử dụng đối với nhân viên tiếp thị khách hàng không chuyên về kỹ thuật

Nói ngắn gọn. Một thiết lập phức tạp

Khách hàng sẽ có thể chỉnh sửa và đăng nội dung theo cách đơn giản, điều này không thể thực hiện được trong thiết lập proxy ngược khi sử dụng trình tạo trang. Điều này là do cài đặt WP_HOME (tôi. e. URL trang chủ) sẽ hướng mọi điều hướng từ máy chủ lưu trữ đến URL công khai, URL mà chúng tôi đang tiếp thị cho khách hàng cũng như thực hiện SEO cho. Và cả trình tạo trang hoặc plugin dịch thuật của chúng tôi đều không hoạt động từ miền công cộng

Tôi cũng cần nhóm web của khách hàng để có thể sao lưu và khôi phục trang web theo cách hơi thân thiện với người dùng

Mã này không phức tạp để thiết lập sau khi nó được thử nghiệm trong một vài biến thể để xem cái nào hoạt động tốt nhất. Xin lưu ý rằng điều này không bao gồm bất kỳ cài đặt Apache hoặc nginx nào để thiết lập proxy ngược, vì việc định cấu hình và khắc phục sự cố tốt nhất nên giao cho chuyên gia lưu trữ. Không cần cài đặt đặc biệt nào trên ngăn xếp LAMP điển hình để mã tùy chỉnh này hoạt động

Mã đầy đủ ở cuối

Tại sao Sửa đổi wp-config. php?

Tệp cấu hình cho WordPress là nơi đáng tin cậy nhất để đặt các cấu hình tùy chỉnh vì nó không bị ghi đè bởi các bản cập nhật WP và bất kỳ mã nào ở đây đều được thực thi trước bất kỳ đầu ra HTML nào. Điều này rất quan trọng vì cookie và tiêu đề phải được đặt trước khi bất kỳ HTML nào được gửi tới trình duyệt

Nó cũng thực thi rất nhanh, vì WP tải các tệp theo thứ tự này

  1. mục lục. php
  2. wp-blog-tiêu đề. php
  3. tải wp. php và trình tải mẫu. php
  4. wp-config. php được tải bởi wp-load. php

Cài đặt URL

Thiết lập chỉ yêu cầu đặt 3 giá trị. Trước tiên, chúng tôi cần biết URL trang chủ công cộng ($public_url), là giao diện người dùng của proxy ngược của chúng tôi. Đây là một URL đủ điều kiện

Sau đó, chúng tôi cần các miền lưu trữ thực tế cho $production_server (product. ví dụ. com) và $staging_server (giai đoạn. ví dụ. máy chủ com). Chúng sử dụng tên miền phụ nhưng có thể dễ dàng là tên miền1. com và tên miền2. com không có thay đổi

Chúng tôi không đủ điều kiện cho các URL này vì biến máy chủ PHP mà chúng tôi sẽ kiểm tra không đủ điều kiện và không có lý do gì để kiểm tra các URL https và http mà CDN của chúng tôi (trong trường hợp này là Cloudflare) xử lý cho chúng tôi

/* Staging and reverse proxy settings */

$public_url 		= 'https://public-server.com';
$production_server 	= 'production.example.com';
$staging_server 	= 'stage.example.com';

Mmmmm, bánh quy 🙂

Để đặt cookie kiểm soát định nghĩa của chúng tôi ( ‘WP_HOME’, “https. //[www. ví dụ. com]” );

Trong trường hợp này, tham số /?cookiesetter

Nếu biến PHP $_SERVER phù hợp, chúng tôi thực thi mã cài đặt cookie, sau đó chuyển hướng bằng 302 đến thư mục /wp-admin/ trên máy chủ sản xuất của chúng tôi. Chuyển hướng 302 được sử dụng vì trình duyệt sẽ nhớ các URL 301 trong nhiều trường hợp và có thể bỏ qua việc tải URL được yêu cầu và do đó, cookie không được đặt

WordPress sẽ tự động chuyển hướng đến /wp-login/ nếu khách truy cập của chúng tôi chưa đăng nhập

Lưu ý rằng chúng tôi có 'https. //’ được mã hóa cứng trong mục tiêu chuyển hướng này, vì chúng tôi không muốn mạo hiểm với trang đăng nhập không an toàn hiển thị cho người dùng WordPress

Chúng tôi đang đặt cookie hợp lệ trong 8 giờ để phù hợp với ngày làm việc. 3600 là một giờ tính bằng giây

if($_SERVER['REQUEST_URI'] == "/?cookiesetter"){

	setcookie("admincookie", 'exists', time()+3600*8, '/', $production_server, true, true);  /* expire in 8 hours */
	header("Location: https://$production_server/wp-admin/", TRUE, 302);
	exit;

}

Việc xóa cookie thường không cần thiết vì chúng tôi có thể truy cập $public_url để xem bất kỳ thay đổi nào được thực hiện đối với trang web, nhưng nó được thêm vào dưới dạng tùy chọn

Một lần nữa, chúng tôi sử dụng một đường dẫn URL cụ thể – /?cookieremover – để kích hoạt thực thi mã, cung cấp cho tuổi thọ cookie của chúng tôi một số âm (điều này sẽ xóa cookie) và chuyển hướng đến trang chủ bằng '/'. Chúng tôi chưa thêm giao thức (https. //) vì nó không quan trọng trong trường hợp này

if($_SERVER['REQUEST_URI'] == "/?cookieremover"){

	setcookie("admincookie", '', time()-3600, '/', $production_server, true, true);   /* expired, removes cookie */
	header("Location: /", TRUE, 302);
	exit;

}

Theo tùy chọn, chúng tôi có thể đã chuyển hướng đến $public_url

Cài đặt máy chủ dàn dựng

Máy chủ dàn của chúng tôi cần đặt cả WP_SITEURL và WP_HOME thành chính nó để tài nguyên và liên kết nội bộ tự tham chiếu. Nói cách khác, cách thức hoạt động của WordPress theo mặc định. Phần này đảm bảo rằng nếu chúng tôi thực hiện sao lưu từ giai đoạn hoặc sản xuất và áp dụng điều này cho máy chủ khác, chúng tôi sẽ thực thi đúng mã

Ngoài ra, chúng tôi cần giữ cho máy chủ chạy thử không được lập chỉ mục của các công cụ tìm kiếm, vì vậy chúng tôi đã đặt một tiêu đề mới bằng PHP để ngăn lập chỉ mục tất cả các trang và tài nguyên trên máy chủ chạy thử

if($_SERVER['HTTP_HOST'] == 'staging_server'){
	
	define( 'WP_SITEURL', "https://$staging_server" );
	define( 'WP_HOME', "https://$staging_server" );

	header("X-Robots-Tag: noindex, nofollow", true);

}

Cài đặt máy chủ sản xuất

Đây là nơi mà việc xử lý động hai cài đặt WP của chúng tôi có ảnh hưởng trực tiếp đến giao diện người dùng như trải nghiệm của người dùng WordPress. Trên thực tế, chúng tôi sẽ đảm bảo rằng bất kỳ ai chỉnh sửa trang web đều ở trên máy chủ lưu trữ thực thay vì được chuyển hướng đến $public_url và không thể thực hiện chỉnh sửa

Trước tiên, hãy kiểm tra xem chúng tôi không ở trên máy chủ dàn dựng

Lưu ý rằng chúng tôi không thể* kiểm tra máy chủ sản xuất vì máy chủ sẽ luôn nhìn thấy chính nó trong URL HTTP_HOST. Máy chủ không nhìn thấy $public_url mà không sửa đổi các tiêu đề, chẳng hạn như x-forwarded-for. Tương tự, giá trị SERVER_NAME cũng giữ nguyên và phụ thuộc vào thiết lập máy chủ, thay vì vị trí lưu trữ

* OK, không thể là một từ mạnh ở đây. Chúng tôi có thể, nhưng nó sẽ liên quan đến việc thiết lập và thử nghiệm nhiều hơn đáng kể từ nhóm web của khách hàng và tôi muốn giảm thiểu điều này

Sau đó, chúng tôi kiểm tra cookie đã đặt của mình và nếu có, hãy đặt cả WP_SITEURL và WP_HOME thành giá trị $production_server. Nếu không có sẵn, chúng tôi đặt biến WP_HOME thành $public_url của chúng tôi

Bây giờ, người dùng của chúng tôi sẽ thấy tất cả các liên kết nội bộ trên trang web trỏ đến $production_server/[path]. Người dùng không có cookie này sẽ theo các liên kết nội bộ tới $public_url/[path], chuyển sang tên miền 'thực' mà chúng tôi đang quảng cáo

if($_SERVER['HTTP_HOST'] != $staging_server ){
	
	if(isset($_COOKIE['admincookie'])){
			
		define( 'WP_SITEURL', "https://$production_server" );
		define( 'WP_HOME', "https://$production_server" );
		
	} else {

		define( 'WP_SITEURL', "https://$production_server" );
		define( 'WP_HOME', $public_url );
	}

}

Theo tùy chọn, chúng tôi cũng có thể đặt WP_SITEURL thành $public_url của mình. Thông thường, máy chủ lưu trữ sẽ cung cấp tài nguyên nhanh hơn máy chủ proxy ngược vì bước trung gian cho mỗi yêu cầu bị loại bỏ. Nếu sử dụng CDN, hãy kiểm tra cái nào hoạt động tốt hơn trong trường hợp của bạn

Bây giờ chúng tôi có một thiết lập với wordpress đằng sau proxy ngược, máy chủ dàn hoạt động chính xác và khách hàng có thể chỉnh sửa, xuất bản, sao lưu và khôi phục trang web với mức độ thân thiện với người dùng tốt

Tại sao không Kiểm tra is_user_logged_in()?

Vấn đề tôi gặp phải là người dùng phải có thể đăng nhập vào WordPress trước is_user_logged_in() là TRUE

Thật không may, trang /wp-login/ có xu hướng chuyển hướng đến URL WP_HOME khi gửi biểu mẫu đăng nhập và vì vậy người dùng của chúng tôi không đăng nhập

Một giải pháp khác mà chúng tôi đã thử nghiệm ban đầu là sử dụng danh sách địa chỉ IP để kiểm soát cài đặt WP_HOME và WP_SITEURL. Đây là một giải pháp hiệu quả nhưng không hiệu quả, đòi hỏi kỹ năng lập trình để duy trì và cập nhật mỗi khi người dùng kết nối từ một địa chỉ IP mới

Hoàn thành mã

Sao chép phần sau vào wp-config của bạn. php ở hoặc gần đầu để thực hiện giải pháp này. Nó sẽ hoạt động tốt sau khi được cập nhật với cài đặt trang web của bạn, hãy cho tôi biết nếu nó không hoạt động và tôi sẽ cố gắng trợ giúp

Apache có hỗ trợ proxy ngược không?

Ngoài vai trò là máy chủ web "cơ bản" và cung cấp nội dung tĩnh và động cho người dùng cuối, Apache httpd (cũng như hầu hết các máy chủ web khác) cũng có thể hoạt động . , also-known-as a "gateway" server.

Apache triển khai proxy ngược như thế nào?

Để định cấu hình Apache làm proxy ngược, hãy làm theo các bước sau. .
Cài đặt máy chủ web Apache
Cài đặt và định cấu hình máy chủ gốc phụ trợ
Bật các mô-đun mod_proxy và mod_http trong httpd của Apache. tập tin conf
Định cấu hình cài đặt ProxyPass và ProxyPassReverse của Apache
Khởi động lại máy chủ web Apache

Máy chủ proxy ngược Apache là gì?

Bạn có thể định cấu hình Máy chủ HTTP Apache làm proxy ngược cho Truy cập web Rational DOORS. Máy chủ proxy ngược cung cấp thêm một lớp bảo mật, bảo vệ máy chủ HTTP trong mạng và cải thiện hiệu suất của các yêu cầu Lớp cổng bảo mật (SSL) .

Proxy đảo ngược được cấu hình như thế nào?

Trong thiết lập proxy ngược, máy chủ web chuyển tiếp yêu cầu HTTP mà nó nhận được từ ứng dụng trình duyệt đến máy chủ phụ trợ thích hợp . Phản hồi HTML từ máy chủ phụ trợ được gửi trở lại trình duyệt thông qua máy chủ web. Do đó, máy chủ web có proxy ngược che giấu sự tồn tại của máy chủ phụ trợ.