رمز گذاری پوشه در هاست: htpasswd و اثرش بر خزنده‌ها

رمز گذاری پوشه با htpasswd سریع‌ترین راه بستن یک مسیر روی سایت است، اما اگر اشتباه اعمال شود خزنده‌ها و ریدایرکت‌ها را هم قفل می‌کند. راهنمای عملی و بی‌حاشیه.

۶ دقیقه به‌روزرسانی ۱۲ مهر ۱۴۰۵

سایت را روی هاست بالا آورده‌اید و حالا یک مسیر مثل /staging یا /admin-old باز مانده که نباید هیچ‌کس ببیندش. سریع‌ترین راهی که به ذهنتان می‌رسد رمز گذاری پوشه است. یک فایل می‌سازید، دو خط داخلش می‌نویسید، و مرورگر رمز می‌خواهد. کار تمام است. تا اینجای ماجرا درست است؛ مشکل از جایی شروع می‌شود که همین دو خط، خزنده گوگل، ریدایرکت HTTPS و اسکریپت‌های خودتان را هم قفل می‌کند و شما فکر می‌کنید سایت خراب شده.

رمز گذاری پوشه با htpasswd در چهار دستور

روی Apache و LiteSpeed، محافظت با پسورد از طریق فایل .htaccess و یک فایل رمز جداگانه انجام می‌شود. اول فایل رمز را بسازید. اگر htpasswd روی سرور نصب است:

htpasswd -c /home/USERNAME/.htpasswd staging
htpasswd /home/USERNAME/.htpasswd seconduser

فلگ -c فقط بار اول می‌آید و فایل را از نو می‌سازد. اگر بار دوم با -c اجرا کنید، کاربر قبلی پاک می‌شود. این را زیاد دیده‌ام. اگر دسترسی SSH ندارید، همان فایل را با یک تولیدکننده آنلاین بسازید و با File Manager آپلود کنید؛ فقط مسیرش را بیرون از public_html بگذارید تا از وب قابل خواندن نباشد.

حالا در پوشه هدف، فایل .htaccess را بسازید یا ویرایش کنید:

AuthType Basic
AuthName "Staging Area"
AuthUserFile /home/USERNAME/.htpasswd
Require valid-user

مسیر AuthUserFile باید مطلق باشد. مسیر نسبی یکی از پرتکرارترین خطاهاست و نتیجه‌اش خطای 500 است، نه پیام رمز. اگر هاست شما PHP را با حالت CGI اجرا می‌کند، ممکن است لازم باشد این خط را هم اضافه کنید:

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

بدون این خط، رمز درست را می‌زنید و باز هم 401 می‌گیرید. علتش این است که وب‌سرور هدر Authorization را به PHP پاس نمی‌دهد و اسکریپت شما فکر می‌کند کسی لاگین نکرده.

چرا رمز گذاری پوشه برای محیط آزمایشی جواب می‌دهد و برای محتوای واقعی نه

برای یک نسخه staging، این روش بهترین انتخاب است. سریع، بدون تغییر کد، و مستقل از فریم‌ورک. اما برای محافظت از محتوای واقعی سایت، انتخاب اشتباهی است. سه دلیل دارد.

  • رمز Basic Auth روی HTTP به‌صورت Base64 رد و بدل می‌شود؛ یعنی رمزنگاری نشده. بدون HTTPS، هر کسی روی مسیر شبکه رمز را می‌خواند.
  • هیچ راهی برای خروج وجود ندارد. مرورگر تا وقتی پنجره را نبندید، رمز را نگه می‌دارد. روی کامپیوتر مشترک، این یعنی نفر بعدی وارد پنل شما می‌شود.
  • مدیریت کاربر سخت است. برای هر نفر باید خط جدید به فایل اضافه کنید و برای حذف، فایل را دستی ویرایش کنید.

اگر محافظت واقعی می‌خواهید، احراز هویت در سطح اپلیکیشن با نشست و کوکی امن، یا محدودکردن دسترسی بر اساس IP، انتخاب درست‌تری است. رمز گذاری پوشه را برای «بستن موقت یک مسیر» نگه دارید، نه برای «امنیت دائمی».

اثر رمز گذاری پوشه بر خزنده‌ها و ایندکس گوگل

این بخش را بیشتر مدیران سایت اشتباه می‌فهمند. وقتی یک پوشه با Basic Auth محافظت می‌شود، گوگل‌بات پاسخ 401 Unauthorized می‌گیرد. این پاسخ یعنی «دسترسی نداری»، نه «وجود ندارم». تفاوت این دو، کل ماجراست.

نتیجه عملی: صفحه از ایندکس حذف نمی‌شود. اگر آن URL قبلاً ایندکس شده و در نتایج جست‌وجو دیده می‌شود، بعد از فعال‌کردن رمز هم در نتایج می‌ماند، فقط کاربر با کلیک روی آن به صفحه رمز می‌رسد. این بدترین حالت است: هم ترافیک می‌آید، هم کاربر چیزی نمی‌بیند، هم نرخ پرش بالا می‌رود.

اگر هدف حذف از ایندکس است، رمز گذاری پوشه ابزار اشتباهی است. باید پاسخ 410 Gone بدهید یا از تگ noindex استفاده کنید. اگر هدف فقط بستن موقت است و بعداً باز می‌شود، 401 مشکلی ایجاد نمی‌کند.

یک نکته دیگر: اگر پوشه محافظت‌شده داخل مسیر اصلی سایت باشد و لینکی از صفحات دیگر به آن اشاره کند، گوگل‌بات آن لینک را دنبال می‌کند و 401 می‌گیرد. این به‌خودی‌خود جریمه نیست، اما اگر تعداد زیادی لینک داخلی به مسیرهای 401 وجود داشته باشد، بودجه خزش سایت هدر می‌رود. قبل از اعمال رمز، لینک‌های داخلی به آن مسیر را حذف کنید.

این‌جا اشتباه می‌کنند: قفل‌شدن ریدایرکت HTTPS

رایج‌ترین صحنه‌ای که در تیکت‌ها می‌بینم این است: مدیر سایت رمز گذاری پوشه را روی پوشه اصلی اعمال می‌کند تا «کل سایت را قفل کند». بعد ریدایرکت اجباری HTTPS را هم در همان .htaccess می‌گذارد. نتیجه یک حلقه بی‌پایان است. مرورگر می‌گوید «تعداد ریدایرکت‌ها بیش از حد مجاز است» و سایت روی هیچ مرورگری باز نمی‌شود.

علت فنی: ترتیب اجرای قواعد در .htaccess مهم است. اگر بلوک AuthType قبل از قواعد RewriteRule بیاید، درخواست HTTP اول به صفحه رمز می‌خورد، بعد ریدایرکت می‌شود، و در درخواست بعدی دوباره همین اتفاق می‌افتد. راه‌حل این است که ریدایرکت HTTPS را در بلوک <VirtualHost> یا در سطح دامنه انجام دهید، نه داخل پوشه‌ای که رمز دارد. اگر روی هاست اشتراکی هستید و دسترسی به VirtualHost ندارید، ریدایرکت را در پوشه اصلی بگذارید و رمز را فقط روی زیرپوشه‌ها اعمال کنید.

علامت تشخیص این خطا ساده است: با curl -I https://example.com چند بار پشت سر هم 301 می‌گیرید و آدرس مقصد هر بار به خودش برمی‌گردد. اگر این را دیدید، اول بلوک رمز را کامنت کنید تا سایت باز شود، بعد ترتیب را درست کنید.

رمز گذاری پوشه روی Nginx

Nginx فایل .htaccess را نمی‌شناسد. اگر سایت شما روی Nginx است و فایل .htaccess می‌سازید، هیچ اتفاقی نمی‌افتد و فکر می‌کنید رمز کار نمی‌کند. باید در بلوک server یا location این را بنویسید:

location /staging/ {
    auth_basic "Staging Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

فایل رمز با همان htpasswd ساخته می‌شود، فقط مسیرش فرق دارد. اگر روی هاست اشتراکی لینوکس هستید و کنترل پنل دارید، معمولاً گزینه «Password Protect Directories» در cPanel همین کار را انجام می‌دهد و نیازی به ویرایش دستی نیست. برای سایت‌های پربازدید که کنترل کامل روی وب‌سرور لازم دارید، سرور اختصاصی این آزادی را می‌دهد که هم Nginx را تنظیم کنید و هم قواعد را در سطح درست اعمال کنید.

قبل از اعمال رمز، این سه چیز را چک کنید

  1. مسیر AuthUserFile مطلق و بیرون از public_html باشد. با ls -la /home/USERNAME/.htpasswd وجودش را تأیید کنید.
  2. HTTPS اجباری درست تنظیم شده باشد. راهنمای نصب SSL روی هاست و اجبار HTTPS بدون حلقه ریدایرکت دقیقاً همین تله را توضیح می‌دهد.
  3. هیچ لینک داخلی به مسیر محافظت‌شده باقی نمانده باشد. با grep -r "/staging" public_html/ پیدایشان کنید.

اگر تازه سایت را بالا آورده‌اید و مطمئن نیستید ساختار پوشه‌ها درست است، راهنمای آپلود سایت روی هاست نقطه شروع بهتری است تا بعداً مجبور نشوید مسیرها را دستی اصلاح کنید.

یک نکته عملی درباره فایل‌های حجیم: اگر پوشه‌ای که رمز می‌گذارید شامل آرشیو یا فایل‌های پشتیبان بزرگ است، هر درخواست رمز، یک بار کل فایل را از دیسک می‌خواند. روی پلن‌های اشتراکی با دیسک کند، این یعنی TTFB بالا. فایل‌های پشتیبان را کلاً از public_html بیرون ببرید، نه اینکه رمز بگذارید. برای بررسی سریع سرعت پاسخ، از ابزارهای رایگان وب‌مستر استفاده کنید.

و اگر روی هاست اشتراکی هستید و می‌خواهید بدانید چه امکاناتی در اختیار دارید، هاست لینوکس گزینه‌ای است که هم cPanel دارد و هم دسترسی به فایل‌سیستم برای ساخت فایل رمز.

پرسش‌های پرتکرار

آیا رمز گذاری پوشه صفحه را از گوگل حذف می‌کند؟

نه. گوگل‌بات پاسخ 401 می‌گیرد که یعنی «دسترسی ندارم»، نه «صفحه وجود ندارد». صفحه در ایندکس می‌ماند و کاربر با کلیک روی نتیجه، به صفحه رمز می‌رسد. برای حذف واقعی باید پاسخ 410 بدهید یا تگ noindex بگذارید.

چرا بعد از رمز گذاری پوشه خطای 500 می‌گیرم؟

تقریباً همیشه به‌خاطر مسیر AuthUserFile است. اگر مسیر نسبی بنویسید یا فایل رمز وجود نداشته باشد، Apache خطای 500 می‌دهد نه 401. مسیر را مطلق بنویسید و با ls وجود فایل را تأیید کنید.

رمز گذاری پوشه روی Nginx چرا کار نمی‌کند؟

چون Nginx فایل .htaccess را نمی‌خواند. باید دستور auth_basic را در بلوک location داخل کانفیگ Nginx بنویسید. اگر به کانفیگ دسترسی ندارید، از گزینه Password Protect در کنترل پنل استفاده کنید.

آیا می‌توانم فقط یک فایل را رمزگذاری کنم، نه کل پوشه؟

بله. به‌جای گذاشتن .htaccess در پوشه، می‌توانید از بلوک <Files "secret.php"> استفاده کنید و قواعد رمز را داخلش بنویسید. این روش وقتی به کار می‌آید که بقیه فایل‌های همان پوشه باید عمومی بمانند.

آیا این مطلب برایتان مفید بود؟