سایت باز می‌شود، اما پیوند مطلب 404 می‌دهد یا تصویر upload نمی‌شود. امشب مسیرهای WordPress و محدودهٔ نوشتن را تکمیل می‌کنیم؛ سپس اعتماد به HTTPS اعلام‌شده از edge را جدا بررسی می‌کنیم.

این جلسه بخشی از دورهٔ آپاچی در ۵۰ شب است. قرارداد نام‌ها، مسیرها و روش اعمال تغییر را در راهنمای دوره بخوان.

محیط: WordPress نصب‌شدهٔ شب چهلم؛ rewrite فعال، حساب runtime برابر wordpress. برای Cloneهای legacy از کاربر Apache استفاده کن.

front controller در config سرور#

در همان Directory اصلی WordPress اضافه کن:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [END]

هدر Authorization برای روش‌های احراز هویت برنامه مانند application password لازم می‌شود؛ آن را در access log ثبت نکن. AllowOverride None باقی می‌ماند؛ WordPress لازم نیست config سرور را بنویسد. در پنل، ساختار پیوند یکتا انتخاب کن و یک نوشته را از نشانی نهایی باز کن.

فقط upload نوشتنی است#

sudo install -d -o wordpress -g wordpress -m 755 \
  /var/www/wordpress/public/wp-content/uploads

اگر دادهٔ موجود داری، مالکیت فقط همین subtree را بررسی و اصلاح کن، نه کل سایت. در RHEL برای همین مسیر نگاشت httpd_sys_rw_content_t بساز و restorecon کن. در میزبان WordPress:

<Directory /var/www/wordpress/public/wp-content/uploads>
    Options -ExecCGI -Indexes
    AllowOverride None
    <FilesMatch "(?i)\.(php[0-9]*|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</Directory>

عدم ExecCGI به‌تنهایی handler PHP-FPM را خاموش نمی‌کند؛ به همین دلیل فایل‌های کد صریحاً رد می‌شوند. یک PHP بی‌ضرر آزمایشی داخل upload قرار بده؛ درخواست آن باید 403 و تصویر مجاز باید 200 بگیرد. فایل آزمون را حذف کن.

وقتی TLS فقط در edge پایان می‌یابد#

در استقرار مستقیم این دوره Apache خودش HTTPS را می‌بیند؛ نیازی به هدر اعتمادشده نیست. اگر WordPress در backend HTTP خصوصی قرار گرفت، edge باید X-Forwarded-Proto را با مقدار خودش جایگزین کند و firewall backend فقط همان edge را بپذیرد. فقط با این پیش‌شرط می‌توان پیش از بارگذاری WordPress در wp-config نوشت:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

پذیرش هدر از اتصال مستقیم عمومی می‌تواند تشخیص HTTPS را جعل کند. WP_HOME و WP_SITEURL، redirect ورود و cookie Secure را از مسیر عمومی بسنج.

بازگشت: config و مالکیت ثبت‌شدهٔ قبل را بازیابی کن. اگر افزونه cache یا مسیر نوشتنی دیگری می‌خواهد، نیاز آن را جدا ارزیابی کن؛ خطای update کد root-owned در این deployment مدیریت‌شده انتظارپذیر است.

منبع: پیکربندی Apache برای WordPress ، HTTPS پشت reverse proxy .