Після додавання правила до .htaccess потрібно також створити файл .htpasswd, де будуть логіни та паролі користувачів. Краще створювати його не в кореневій папці сайту, а в якійсь вкладеній, щоб до нього не можна було просто дістатися. Наприклад, у папці /auth. У записів у файлі .htpasswd має бути формат «користувач: пароль». Але для безпеки паролі краще не зберігати у файлі у відкритому вигляді, а зашифрувати. Для цього зайдіть на сайт генератора .htpasswd, введіть там логін з паролем і натисніть «Сгенерировать». Генератор паролів для .htpasswd — Як налаштувати доступ до сайту по паролю в .htaccess Скопіюйте рядок і додайте його до файлу .htpasswd. Деталі входу для кожного нового користувача в цьому файлі повинні йти з нового рядка. На сайті використовуйте звичайну версію пароля, зашифрована потрібна тільки для того, щоб не зберігати пароль у відкритому вигляді. Вміст файлу .htpasswd — Як зробити доступ до сайту за паролем у .htaccess Заблокувати ботів Якщо ви помітили, що сайт почав повільніше працювати, тому що його сканують різні роботи, забороніть їм це робити за допомогою такої директиви: # Блокування ботів SetEnvIfNoCase User-agent (Abonti|AhrefsBot|Aport|AspiegelBot|asterias|Baiduspider|BDCbot|Birubot|BLEXBot|BUbiNG|BuiltBotTough|Bullseye|BunnySlippers|Butterfly|CamontSpider|CCBot|Cegbfeieh|CheeseBot|CherryPicker|coccoc|CopyRightCheck|cosmos|crawler|Crescent|DeuSu|discobot|DittoSpyder|DnyzBot|DomainCrawler|DotBot|EasouSpider|EmailCollector|EmailSiphon|EmailWolf|EroCrawler|Exabot|ExtractorPro|Ezooms|FairShare|Fasterfox|FeedBooster|Foobot|Genieo|Gigabot|GrapeshotCrawler|Harvest|hloader|HTTrack|humanlinks|HybridBot|Incutio|InfoNaviRobot|InternetSeer|IstellaBot|JamesBOT|JennyBot|k2spider|kmSearchBot|larbin|LexiBot|libWeb|libwww|Linguee|LinkExchanger|LinkextractorPro|linko|LinkWalker|lmspider|LNSpiderguy|magpie|MaxPointCrawler|MegaIndex|memoryBot|MIIxpc|Mippin|MJ12bot|MLBot|moget|MSIECrawler|NetAnts|NetpeakCheckerBot|NICErsPRO|NjuiceBot|NPBot|Nutch|OLEcrawler|Openfind|PostRank|ProWebWalker|Purebot|PycURL|RepoMonkey|Riddler|RMA|Scrapy|SemrushBot|serf|SeznamBot|SISTRIX|SiteBot|SiteSnagger|Serpstat|Slurp|SnapPreviewBot|Sogou|Soup|SpankBot|spanner|spbot|Spinn3r|SpyFu|suggybot|SurveyBot|suzuran|SWeb|Teleport|Telesoft|TheNomad|TightTwatBot|Titan|True_Robot|ttCrawler|turingos|TurnitinBot|UbiCrawler|UnisterBot|Unknown|VCI|Vedma|Voyager|WBSearchBot|WebAuto|WebBandit|WebCopier|WebEnhancer|WebmasterWorldForumBot|WebReaper|WebSauger|WebStripper|Wotbox|Yeti|YottosBot|Zao|Zeus|ZyBORG) not-allowed=1 Order Allow,Deny Allow from ALL Deny from env=not-allowed Це лише деякі боти, взагалі їх набагато більше. Якщо директива не має бота, який навантажує ваш сайт, додайте його самостійно. Заборонити індексацію каталогів За замовчуванням, якщо хтось безпосередньо звернеться до якогось каталогу у вас на хостингу, веб-сервер покаже його вміст. В результаті будь-який зможе покопатися у ваших файлах, завантажити їх і в гіршому випадку знайти вразливості. Як заборонити індексацію каталогів у .htaccess Такі речі обов’язково треба забороняти. Не потрібно ризикувати безпекою вашого сайту. У .htaccess це робиться за допомогою директиви Options. Вона зробить так, щоб при прямому зверненні до каталогу виникала 403 помилка: # Заборонити індексацію каталогів Options -Indexes Налаштувати редирект У цьому розділі розглянемо кілька найбільш популярних ситуацій, коли потрібно налаштувати редирект. Але взагалі це велика тема з купою нюансів. Докладно розглядаємо їх в окремій статті: Як зробити 301 редирект у .htaccess Редирект з однієї сторінки на іншу (якщо змінили URL-адресу сторінки): Redirect 301 /old-url-1 /new-url-1 Редирект з одного файлу в кореневій папці сайту на інший (якщо змінили назву файлу): Redirect 301 /contact-us.php/contact.php Редирект усіх сторінок сайту на такі ж сторінки на іншому домені: Redirect 301 / https://vashdomen.ua/ Редирект усіх файлів з розширенням .html на такі ж файли з розширенням .php: RedirectMatch 301 (.*).html /$1.php Перенаправлення домену без www на домен з www: RewriteEngine On RewriteCond %{HTTP_HOST} !^www..* [NC] RewriteRule ^(.*) http://www.%{HTTP_HOST}/$1 [R=301] І навпаки — перенаправлення домену з www на домен без www: RewriteEngine On RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Примусове перенаправлення з HTTP на HTTPs (попередньо потрібно встановити SSL-сертифікат): RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] Захистити картинки від крадіжки Інша назва такого налаштування — захист від хотлінкінгу (від англ. hotlinking — використання прямих посилань). Ідеться про ситуацію, коли хтось розмістив у себе на сайті зображення за посиланнями на ваш сервер. У результаті виходить так, що зображення завантажуються з вашого сервера, але трафік йде на чужий сайт. Тобто хтось нишком витрачає ресурси вашого хостингу. Відучити від цього можна за допомогою такої директиви: # Заборона на крадіжку картинок (hotlinking) RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^https://(www.)?vashdomen.com/.*$ [NC] RewriteRule .(gif|jpg|swf|flv|png)$ https://www.vashdomen.com/feed.gif [R=302,L] Працює ця директива так: ви розміщуєте у себе на сервері спеціальне зображення для таких злодіїв, і коли вони розміщують будь-яке ваше зображення у себе на сайті, замість нього відображається саме заготовлена картинка. Що саме завантажити як заготовлену картинку — справа ваша. Можете намалювати у фотошопі плакат «Я краду чужі картинки» або банер із рекламою власних послуг. Тут все залежить від вашої фантазії та бажання покарати хитрунів. Шлях до зображення для злодюжок вказується в директиві RewriteRule. Призначити свої сторінки помилок Якщо хочете відображати замість стандартних сторінок з помилками сторінки зі своїм дизайном, використовуйте таку директиву: # Свої сторінки помилок ErrorDocument 403 /errors/403.html ErrorDocument 404 /errors/404.html ErrorDocument 500 /errors/500.html ErrorDocument 504 /errors/504.html У цій директиві /errors/403.html це абсолютний шлях до файлу сторінки (без урахування доменного імені). Повний список кодів стану ви знайдете в статті «Коди стану HTTP». Не обов’язково створювати свою сторінку для кожного коду, можна тільки для найпоширеніших помилок: 404 Not Found та 500 Internal Server Error. В ідеалі нова сторінка помилки повинна бути не тільки красивою, але й простими словами пояснювати причини помилки, а також містити посилання, щоб відвідувач міг повернутися на сайт. Налаштувати стиснення файлів Для цього Apache використовується модуль mod_deflate. У прикладі перелічені не всі типи файлів. Якщо потрібно, додайте вручну типи, яких бракує. Список MIME-типів файлів # Стиснення для файлів HTML, CSS, JavaScript, Text, XML та шрифтів AddOutputFilterByType DEFLATE application/javascript application/x-javascript application/xml application/xhtml+xml image/svg+xml text/css text/html text/javascript text/plain text/xml Налаштувати кешування Встановлюємо скільки часу (в секундах) у браузері відвідувача повинні зберігатися файли тих чи інших типів. У прикладі перелічені не всі типи файлів. Якщо потрібно, додайте вручну типи, яких бракує. Список MIME-типів файлів # Кешування файлів ExpiresActive On ExpiresDefault A300 ExpiresByType image/x-icon A2419200 ExpiresByType application/x-javascript A3600 ExpiresByType text/css A3600 ExpiresByType image/gif A604800 ExpiresByType image/png A604800 ExpiresByType image/jpeg A604800 ExpiresByType text/plain A300 ExpiresByType application/x-shockwave-flash A604800 ExpiresByType video/x-flv A604800 ExpiresByType application/pdf A604800 ExpiresByType text/html A300 Розшифрування відрізків часу (для зручності): 300 — 5 хвилин; 3600 — 1 година; 86400 — 1 день; 604800 — 7 днів; 2419200 — 4 тижні. Змінити параметри PHP Збільшити час очікування веб-сервера під час виконання скрипту. Допоможе уникнути зависання веб-сервера під час обробки важких скриптів. # Час очікування веб-сервера під час виконання скрипту php_value max_execution_time 60 Визначити максимальний розмір файлу, який можна завантажити (у прикладі — 128 Мб): # Максимальний розмір файлу, що завантажується php_value upload_max_filesize 128M Вивести помилки РНР в окремий файл: # Виведення помилок PHP в окремий файл php_flag log_errors on php_value error_log /home/username/public_html/php_errors.log У цій директиві /home/username/public_html/php_errors.log шлях до файлу з логами. Не забудьте змінити його. Ці директиви не завжди підтримуються на віртуальному хостингу. Наприклад, у нас на віртуальному хостингу їх використовувати вийде лише на VPS. Причина в тому, що веб-сервер, який працює в режимі suPHP, не підтримує директиви php_flag та php_value. Рішенням у цій ситуації буде використовувати розділ «Select PHP Version» у панелі керування cPanel. Там також можна змінити ці параметри. Альтернативний варіант — створити локальний файл php.ini та прописати ліміти в ньому. Якщо .htaccess не працює Коли ви додаєте правило до .htaccess і не спостерігаєте очікуваного ефекту, причина не завжди очевидна. Особливо на віртуальному хостингу, де немає доступу до основних логів веб-сервера. Ось основні причини, чому так може бути. Причина №1: .htaccess вимкнено в httpd.conf Можливість використання .htaccess прописується в головному конфігураційному файлі Apache за допомогою директиви AllowOverride. Якщо вона вказана зі значенням None, веб-сервер ігноруватиме .htaccess. Така проблема може бути лише на VPS або виділеному сервері. Якщо у вас віртуальний хостинг, справа 100% у чомусь іншому. Причина №2: Директиву не можна використовувати у .htaccess Ще одна особливість директиви AllowOverride — з її допомогою можна дозволити в .htaccess всі директиви, а можна лише окремі групи директив. Докладніше про цю директиву читайте в офіційній документації Apache. # Дозволити у .htaccess всі директиви AllowOverride All # Дозволити в .htaccess тільки директиви груп «Limit» та «FileInfo» AllowOverride Limit FileInfo Ще є директива AllowOverrideList, за допомогою якої можна перерахувати конкретні директиви, які дозволені в .htaccess (а не групи директив, як у випадку AllowOverride). Докладніше про цю директиву читайте в офіційній документації Apache. # Заборонити всі директиви, крім директив Redirect та RedirectMatch AllowOverride None AllowOverrideList Redirect RedirectMatch # Дозволити групу директив «AuthConfig» # Дозволити директиви CookieTracking та CookieName із групи «FileInfo» AllowOverride AuthConfig AllowOverrideList CookieTracking CookieName Може бути так, що при спробі використати заборонену директиву в .htaccess виникне помилка 500 Internal Server Error. Але це не обов’язково: AllowOverride має також параметр Nonfatal, завдяки якому можна не виводити помилку, а просто робити запис у логах. Перевірити логи помилок вдасться лише у користувачів VPS або виділеного сервера. На віртуальному хостингу до цих логів доступу немає. Причина №3: Неправильний синтаксис директиви У випадку з друкарською помилкою результат може бути таким самим, як ніби директива була забороненою — помилка 500 Internal Server Error. Якщо адміністратор сервера не вимкнув таку поведінку за допомогою Nonfatal у головному конфігураційному файлі. Якщо хочете, можете перевірити вміст файлу на друкарські помилки за допомогою спеціального сервісу — валідатора .htaccess. Причина №4: Неправильна назва файлу Ім’я файлу повинне починатися з крапки, в ньому повинні бути лише маленькі літери і не повинно бути розширення. Файл буквально називається .htaccess. Не htaccess, не .htaccess.txt і не .Htaccess. Теоретично, справа також може бути в тому, що стандартне ім’я .htaccess змінили в головному конфігураційному файлі веб-сервера. Це робиться за допомогою директиви AccessFileName. Наприклад, ось так: # Змінити ім'я файлу .htaccess AccessFileName .config Причина №5: На сервері кілька файлів .htaccess Правила .htaccess виконуються у послідовності, в якій їх знайшов Apache. Тобто спочатку директиви з .htaccess у кореневій папці, потім директиви з .htaccess у дочірніх папках. Через це може статися так, що директиви у файлі, який розташований глибше в дереві каталогів, перезапишуть директиви з файлів, які знаходяться вище. Причина №6: Неправильна послідовність директив Найчастіше таке буває з директивами для редиректу RewriteRule. Якась директива, яка стоїть вище, може перетворити URL-запит таким чином, що він більше не підходитиме під умови в наступних директивах. При цьому сама по собі директива може бути складена правильно. Щоб перевірити цей сценарій, спробуйте переставити непрацюючу директиву на початок .htaccess і повторно зберегти файл. Що далі Сподіваємося, стаття була для вас корисною. Якщо ви знайшли помилку або у статті не вистачає якоїсь важливої інформації, поділіться своїми думками у коментарях. Чи була ця стаття корисною? 4shares Facebook0 Twitter2 Email2 Похожие статьи Права доступу до файлів та папок у Linux Як користуватися FTP-клієнтом FileZilla Як зайти на сервер по FTP Як налаштувати 301 редирект Як звільнити місце на хостингу В яку папку завантажувати файли сайту Рубрики Wiki SSL-сертифікати Установка SSL Домени DNS Пошта Правила реєстрації Панелi керування cPanel SolusVM Webuzo Сервіси HOSTiQ CDP-бекапи Панель клієнта Партнерська програма Питання оплати Створити сайт OpenCart WordPress Конструктор сайтів Хостинг Cloud VPS Помилки на хостингу Файли Купити домен Наші послуги Хостинг сайтів Бізнес-хостинг Реселінг хостингу VPS / VDS хостинг Cloud VPS Оренда виділених серверів Реєстрація доменних імен Купити SSL-сертифікат Купити хостинг з доменом Студентський хостинг Про компанію Головна HOSTiQ Наша компанія Наша служба підтримки Хостинговая панел cPanel Наше обладнання Відгуки про HOSTiQ.ua Партнерська програма хостингу Автовстановлювач CMS Контакти Купити хостинг