دسته بندی:

آموزش محافظت از یک فولدر با پسورد در .htaccess

برای گذاشتن رمز روی یک پوشه با .htaccess دو چیز لازم دارید: یک فایل رمز که با ابزار htpasswd ساخته می‌شود و بیرون از مسیر عمومی سایت نگه داشته می‌شود، و چهار دستور احراز هویت که داخل خودِ همان پوشه قرار می‌گیرند. این روش که HTTP Basic Authentication نام دارد ساده و سریع است، اما نام کاربری و رمز را فقط با base64 کدگذاری می‌کند و رمزنگاری نمی‌کند؛ پس بدون HTTPS نباید به آن تکیه کرد.

پیش‌نیازها

وب‌سروری لازم است که فایل .htaccess را بخواند. آپاچی و LiteSpeed این فایل را می‌خوانند، اما nginx اصلاً .htaccess را پردازش نمی‌کند و باید بلوک auth_basic را مستقیم در کانفیگ سرور بنویسید. روی هاست‌های اشتراکی که با کنترل‌پنل عرضه می‌شوند، مثل هاست لینوکس ایران که با cPanel ارائه می‌شود، همین کار را از خودِ پنل هم می‌توان انجام داد. اگر مطمئن نیستید وب‌سرور میزبان‌تان .htaccess را می‌خواند یا نه، پیش از شروع از پشتیبانی بپرسید. همچنین در کانفیگ سرور باید برای آن مسیر AllowOverride AuthConfig یا AllowOverride All تنظیم شده باشد، وگرنه سرور به‌جای پنجره‌ی ورود، خطای ۵۰۰ برمی‌گرداند.

ساخت فایل رمز با htpasswd

فرض کنید می‌خواهید پوشه‌ی /home/user/public_html/important/ را قفل کنید و کاربر admin بسازید. فایل رمز را در مسیری خارج از public_html بسازید تا حتی اگر روزی قوانین سرور تغییر کرد، از طریق مرورگر قابل دانلود نباشد:

  • mkdir -p /home/user/.htpasswds
  • htpasswd -B -c /home/user/.htpasswds/important admin

ابزار دو بار رمز را می‌پرسد (New password و Re-type new password) و در پایان پیام Adding password for user admin را نشان می‌دهد. سوئیچ -c یعنی «فایل را از نو بساز» و اگر فایل از قبل وجود داشته باشد آن را پاک می‌کند؛ پس برای افزودن کاربر دوم حتماً بدون -c اجرا کنید:

  • htpasswd -B /home/user/.htpasswds/important editor
  • حذف یک کاربر: htpasswd -D /home/user/.htpasswds/important editor

سوئیچ -B رمز را با الگوریتم bcrypt ذخیره می‌کند. این نکته مهم است: حالت پیش‌فرض htpasswd هنوز MD5 قدیمی آپاچی (apr1) است و در سیستم‌های امروزی توصیه نمی‌شود. اگر روی سرورهای قدیمی با گزینه‌ی -d (crypt) فایل ساخته‌اید، آن ورودی‌ها را با -B بازسازی کنید، چون crypt فقط هشت کاراکتر اول رمز را در نظر می‌گیرد. در پایان دسترسی فایل را محدود کنید: chmod 640 /home/user/.htpasswds/important

دستورهای فایل .htaccess

فایل .htaccess را داخل همان پوشه‌ای بسازید که می‌خواهید محافظت شود، یعنی /home/user/public_html/important/.htaccess. اگر آن را در ریشه‌ی public_html بگذارید، کل سایت پشت رمز می‌رود. محتوای فایل:

  • AuthType Basic
  • AuthName "Restricted Area"
  • AuthUserFile /home/user/.htpasswds/important
  • Require valid-user

مسیر جلوی AuthUserFile باید مسیر مطلق روی دیسک باشد، نه آدرس اینترنتی. عبارت داخل AuthName نام آن ناحیه‌ی محافظت‌شده است؛ مرورگرهای امروزی لزوماً این متن را در پنجره‌ی ورود نمایش نمی‌دهند، پس روی آن حساب باز نکنید. اگر می‌خواهید فقط یک کاربر مشخص اجازه‌ی ورود داشته باشد، به‌جای خط آخر بنویسید Require user admin

چرا HTTPS اجباری است

مرورگر در هر درخواست، رشته‌ی username:password را با base64 کدگذاری می‌کند و در هدر Authorization می‌فرستد. base64 رمزنگاری نیست؛ یک تبدیل برگشت‌پذیر است و هر کسی که ترافیک را ببیند در یک ثانیه آن را به متن ساده برمی‌گرداند. بنابراین Basic Auth روی http:// عملاً یعنی ارسال رمز به شکل باز روی شبکه. پیش از فعال کردن این قفل، برای دامنه یک گواهینامه SSL نصب کنید و درخواست‌های http را به https ریدایرکت کنید. نکته‌ی دوم اینکه مرورگر پس از ورود، هدر را تا بسته شدن پنجره تکرار می‌کند و Basic Auth دکمه‌ی خروج ندارد.

این روش چه چیزی را محافظت نمی‌کند

محدودیت روی مسیر اعمال می‌شود، نه روی محتوا. اگر همان فایل نسخه‌ای دیگر در پوشه‌ای بیرون از ناحیه‌ی قفل‌شده داشته باشد یا از مسیر دیگری سرو شود، بدون رمز در دسترس است. همچنین Basic Auth به‌تنهایی سقف تلاش ورود ندارد؛ برای مقابله با حدس‌زدن خودکار رمز، رمز بلند انتخاب کنید و اگر روی سرور اختصاصی ایران دسترسی ریشه دارید، از fail2ban کمک بگیرید تا آی‌پی‌های پرتلاش را ببندد. قفل کردن مسیرهای پویا هم دردسر دارد: مثلاً رمزگذاری پوشه‌ی wp-admin وردپرس، فایل admin-ajax.php را می‌شکند و بخشی از قالب و افزونه‌ها در بخش عمومی سایت از کار می‌افتد.

معادل گرافیکی در کنترل‌پنل

اگر با ترمینال راحت نیستید، هر دو کنترل‌پنل همین کار را با فرم انجام می‌دهند. در cPanel ابزار Directory Privacy در بخش Files قرار دارد؛ پوشه را انتخاب می‌کنید، برچسبی برای آن می‌نویسید و کاربر می‌سازید. در دایرکت‌ادمین همین قابلیت با نام Password Protected Directories زیر بخش Advanced Features قرار دارد. هر دو پشت صحنه دقیقاً همان فایل .htpasswd و همان چهار دستور را می‌سازند، پس بعداً می‌توانید خروجی را دستی ویرایش کنید.

آزمایش نتیجه و خطاهای رایج

برای اطمینان، بدون ورود رمز درخواست بزنید: curl -I https://example.com/important/ باید پاسخ 401 Unauthorized و هدر WWW-Authenticate: Basic بدهد. سپس با curl -u admin https://example.com/important/ ورود را بسنجید. سه خطای پرتکرار:

  • خطای ۵۰۰: یا AllowOverride اجازه نمی‌دهد، یا مسیر AuthUserFile غلط است. لاگ خطای آپاچی معمولاً پیام could not open password file را ثبت می‌کند.
  • پنجره‌ی رمز باز می‌شود ولی رمز درست هم قبول نمی‌شود: فایل رمز برای کاربر وب‌سرور خواندنی نیست، یا رمز با الگوریتمی ساخته شده که آن نسخه از سرور پشتیبانی نمی‌کند.
  • هیچ اتفاقی نمی‌افتد: وب‌سرور nginx است و .htaccess را نمی‌خواند، یا فایل را در پوشه‌ی اشتباه گذاشته‌اید.

یک هشدار آخر درباره‌ی نمونه‌های قدیمی اینترنت: دستورهای Order allow,deny و Satisfy any مربوط به آپاچی ۲٫۲ هستند و در آپاچی ۲٫۴ که امروز روی سرورها نصب است جای خود را به Require و بلوک‌های <RequireAny> داده‌اند. این نحو قدیمی فقط تا وقتی کار می‌کند که ماژول سازگاری mod_access_compat روی سرور بارگذاری شده باشد؛ اگر بارگذاری نشده باشد نتیجه خطای ۵۰۰ است، و اگر هم بارگذاری شده باشد قاطی کردن نحو قدیم و جدید در یک فایل رفتاری غیرقابل پیش‌بینی می‌سازد. نحو تازه را بنویسید و نمونه‌های اینترنتی مربوط به آپاچی ۲٫۲ را کپی نکنید.

ارسال نظر