Ръководство за начинаещи на .htaccess за дизайнери и разработчици

Сред многото различни инструменти за персонализиране на уеб сървъра, .htaccess конфигурационният файл е огромен актив. Можеш бързо пренастройване на типовете документи, анализ на двигатели, пренасочване на URL адреси, и много други важни характеристики. Уебмастъри, които не са много технически, не могат да влязат в спецификата на управление на вашия собствен .htaccess файл. Но самата тема е очарователна и си струва да се изследва.

За тази статия искам да представя някои от по-целенасочените концепции за уебмастъри и уеб разработчици. Всеки, който е стартиране на собствен уебсайт на Apache сървър определено ще искате да разберете как да управлявате своя .htaccess файл. То осигурява толкова много възможности за персонализиране и то може да работи на всички уеб езици от PHP на Ruby.

В долната част на тази публикация добавих някои външни webapps към помогнете на новодошлите да генерират динамично своите .htaccess файлове.

Защо да използвате .htaccess файл?

Това е голям въпрос и може би трябва да започнем с отговор “какво е .htaccess файл”? Това е много специален конфигурационен файл, използван от уеб сървъра на Apache. Файлът .htaccess може да съобщи на уеб сървъра как да представяте различни форми на информация и как да се справяте с различни заглавия на HTTP заявки.

Наистина това е средство децентрализация да организирате настройките на уеб сървъра. Един физически сървър може да притежава 50 различни уебсайта, всеки със собствен .htaccess файл. Тя дава много власт на уебмастъри, което иначе би било невъзможно. Но защо трябва да го използвате?

Най-голямата причина е сигурността. Можеш заключва определени директории или ги защитава с парола. Това е чудесно за частни проекти или нови системи за управление на съдържанието, където искате малко повече сигурност. Но има и общи задачи като пренасочване на 404 съобщения за грешка към определена уеб страница. Това отнема само един ред код и може драматично да повлияе на това, как посетителите реагират на липсващите страници.

Честно казано, не мога да кажа много, за да убедя другите, че един .htaccess файл си струва да се разбере. След като го видите в действие, можете да разпознаете цялата стойност, която идва от този малък конфигурационен файл. Също така се надявам, че останалата част от тази статия може да представи някои проницателни теми, за да приведат уебмастърите в светлината на управлението на .htaccess конфигурация.

Разрешаване / забрана на достъпа

Възможно е да разпознаете потенциалните нежелани посетители и да им откажете достъп до уебсайта си. Това може да бъде малко екстремно, но ако знаете, че човек или група хора са насочили Вашия уебсайт, има някои възможности за избор. Можете да изберете препратка към домейн, за да откажете или забраните на посетители чрез IP адрес.

За да позволите, откажете отказ от 255.0.0.0 откажете от 123.45.6. позволете от всички 

Тези примерни кодове бяха копирани от Htaccess Guide, тъй като те са идеалният шаблон за започване. Забележете, че на втория IP адрес липсва 4-то цяло число. Този кодов блок ще се насочи към първия IP (255.0.0.0) и всеки IP в границите на 123.45.6.0-255, след това разрешете всички останали трафик. Уеб администраторите може да не използват това толкова често, колкото други техники, но е полезно да се разбере.

Предотвратяване на списъка с директории

Ще има моменти, когато имате отворена директория, която е настройте, за да позволите сърфиране по подразбиране. Това означава, че потребителите могат да виждат всички файлове, изброени във вътрешната структура на директориите, като папката с изображения. Някои уебмастъри не искат да позволят изброяване на директория и за щастие кодовия фрагмент е доста лесен за запомняне.

Опции - Индекси 

Видях този отговор да се представя безброй пъти през препълването на стака и може да е един от най-лесните .htaccess правила за запомняне.

Възможно е всъщност създайте множество .htaccess файлове във всяка от тези директории така че може би един от тях е защитен с парола, но другите не са. И все още можете да запазите Опции - Индекси така че посетителите да не могат да разглеждат вашия уебсайт / изображения / папка.

Защита с парола

Защитата на паролите директории е много обичайна процедура за осигуряване на административни области и други папки от решаващо значение за вашия уебсайт. Понякога само искате да предложите достъп до малка група хора. В други случаи паролите трябва да попречат на хакерите да получат достъп до административния панел на уебсайта ви. Но и в двата случая това е много мощно решение за редица проблеми.

Налице е удобно ръководство за защита с парола, което очертава важните кодови фрагменти. Ще трябва да го направите генерира файл с пароли, който съхранява идентификационните данни за потребителско име и парола. Това е начинът, по който Apache може да провери срещу това, което потребителят въвежда, за да види дали те трябва да получат достъп. Забележете как ще трябва да генерирате мостра за потребителското си име и парола.

Бих препоръчал да използвате този htpassword генератор, така че можете да спестите малко време. Синтаксисът винаги ще излезе перфектен и не е необходимо да шифровате паролата сами. А другата голяма възможност е да защитите с парола цял списък с указатели. Можем да видим този пример в галерията на CSS-Tricks code snippets.

AuthType Basic AuthName "Тази област е защитена с парола" AuthUserFile /full/path/to/.htpasswd Изисква валиден потребител 

Сигурност за WordPress

За да използваме идеята за защита на паролите, нека покажем пример от реалния свят. Този по-сложен кодов фрагмент ще бъде принудително удостоверяване на потребителя за всеки, който има достъп до файла на WordPress wp-login.php. Ще намерите оригиналния източник на Ask Apache, който има много други фрагменти за защита на WordPress.

 Отказване на поръчката, Разрешаване на отказ от всички Задоволителни Всички AuthName "Защитено от AskApache" AuthUserFile /web/askapache.com/.htpasswda1 AuthType Основен Изисква валиден потребител  

И ако ще следвате тези .htaccess правила, може също да помогнете за защитата на паролата на административната област. Обикновено WP-login.php Файлът ще получи най-много хитове от хора, които се опитват да пробият груба сила във вашата система. Така че дори само примерните кодове по-горе ще бъдат повече от достатъчно сигурност за вашия WordPress сайт.

Правила за пренаписване на URL адреси за HTTP

Пренаписването на URL адреси вероятно е едно от най-често използваните за .htaccess файлове. По подразбиране инсталациите на WordPress могат генерира .htaccess файл директно от административния панел. Това ви позволява да създавате доста URL адреси, които нямат структурата .php? P = 1.

Искам да погледна този пример за пренаписване как да се актуализират подчертаващите тирета оттогава съдържа много от най-важните елементи.

(Html ​​| php) $ - [S = 4] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _] *) _ (_ [^ _] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4- $ 5 [E = uscor: Да] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ ([^ _] ] *) _ (. *) $ $ 1- $ 2- $ 3- $ 4 [E = uscor: Да] RewriteRule ^ ([^ _] *) _ ([^ _] *) _ (. *) $ $ 1- $ 2- $ 3 [E = uscor: Да] RewriteRule ^ ([^ _] *) _ (. *) $ $ 1- $ 2 [E = uscor: Да] RewriteCond% ENV: uscor ^ Да $ RewriteRule (. *) Http: //d.com/$1 [R = 301, L] 

RewriteEngine и RewriteBase най-често може да се зададе на тези точни стойности. Но трябва да включите RewriteEngine, за да работи нещо друго. Има много онлайн ръководства, които обясняват как да се даде възможност на mod_rewrite и вашия хостинг доставчик също да помогне.

Забележете, че синтаксисът следва модел на RewriteRules на върха. Тези правила са свикнали съвпадат с случаи, които се изпращат като HTTP заявка. На тях се отговаря от RewriteRule, който в този случай пренасочва всичко към домейна d.com. Крайните скоби, като [R = 301, L], се наричат ​​флагчета за презапис, които са важни, но повече от разширена тема.

Синтаксисът mod_rewrite определено е малко объркващ, но не се смущавайте! Фрагментите могат да изглеждат много по-лесно в други примери.

Когато просто започнете, трябва да препоръчам този web_product, който ви помага да генерирате проби от код с помощта на реални URL адреси. Това е брилянтен инструмент, защото можете да търсите различни елементи в синтаксиса, за да видите какво всъщност правят в правилата за пренаписване. Ето още един голям урок с по-прост пример за изучаване:

RewriteRule ^ dir / ([0-9] +) /? $ /Index.php?id=$1 [L] 

Не се опитвайте да се претоварвате наведнъж. Отне ми доста повече от 3-4 месеца, за да започна наистина да разбирам как да пренаписвам URL адреси с [0-9a-zA] и подобни модели. Продължавай да практикуваш и във времето обещавам, че ще получиш тези неща като познатото от здравия разум.

Кодови фрагменти за уеб администратори

Обичам лесни за използване откъси и искам да събера тази малка колекция от уместни .htaccess кодове за уебмастъри. Всяка от тези идеи може да се впише добре във вашия собствен файл .htaccess заедно с други блокови кодове. Повечето от тези откъси са страхотни решаване на бързи проблеми или поправки в средата на вашия уеб сървър. Представете си перфектната настройка на Apache за чисто нови уебмастъри, само за да започнете онлайн.

Настройка на DirectoryIndex

Командата за DirectoryIndex се използва често в един ред. Можете да кажете на Apache кои документи трябва първоначално да се третират като “основен” документ. По подразбиране това ще стане целеви елементи като index.html, index.php, index.asp и други индексни файлове. Но използвайки този кодов фрагмент, който съм копирал по-долу, имате възможност да направите този коренен документ каквото искате.

DirectoryIndex index.html index.cgi index.php 

Редът на документите трябва да започва с най-важното и да се движи през редиците до най-малко важните. Така че, ако нямаме HTML или CGI файл, тогава ще се върнете към резервната index.php. Можете дори да посочите тези файлове home.php или someotherfile.php и това е валиден синтаксис.

Принуди WWW или не-WWW поддомейн

Google може да работи с двете версии на домейна на уебсайта Ви, ако не посочите www.domain.com или просто domain.com. Според моя опит е най-добрата практика изберете един от тях и го задайте като единствения избор чрез .htaccess. Тогава Google няма да индексира различни URL адреси, като някои сочат към поддомейна WWW, докато други не.

# Сила WWW Поддомейн RewriteEngine На RewriteCond% HTTP_HOST ^ domain.com [NC] RewriteRule ^ (. *) $ Http://www.domain.com/$1 [L, R = 301] # Не Поддомейн RewriteEngine В RewriteCond% HTTP_HOST! ^ Domain.com $ [NC] RewriteRule ^ (. *) $ Http://domain.com/$1 [L, R = 301] 

Този кодов фрагмент идва от архива на CSS-Tricks и осигурява много удобно решение. Трябва да актуализирате домейна, за да бъде това, което ви трябва за собствения си уебсайт. В противен случай ще има проблеми и веднага ще забележите! Но аз силно подкрепям принуждаването на една от тези две възможности и тя е на върха на списъка ми със задачи след стартирането на нов уебсайт.

Принудително изтегляне на медийни файлове

Друг доста важен фрагмент позволява принуждаването на определени типове медии изтегляне, вместо да се показва в браузъра. Веднага мога да мисля за PDF документи и MP3 аудио файлове, които могат да бъдат представени във формат, който може да бъде изтеглен, но как да го направите уверете се, че те могат да се изтеглят? Намерих подобна статия, публикувана на Htaccess Guide, която очертава този кодов фрагмент.

Приложението AddType / octet-stream .zip .mp3 .mp4 

Чувствайте се свободни да включите още повече типове файлове в края на този ред. Всички мултимедийни формати, използващи MIME-типа от октет-поток, ще могат да се свалят. Принуждаването на това чрез .htaccess е много директен път, за да се гарантира, че хората не могат да видят тези файлове в браузъра.

Потребителски документи за грешки

Последното последно парче, което искам да добавя, е пълен шаблон за персонализирани документи за грешки. Обикновено тези кодови номера се виждат само на края на сървъра. Но има много такива документи за грешки, с които трябва да сте запознати. Може да има няколко примера 403/404 грешки и 301 пренасочване.

Този шаблон за код на грешка започва от 100 и се движи нагоре в 500 грешки. Моля, обърнете внимание, че вие ​​очевидно не се нуждаете от всичко това. Необходими са само най-често срещаните грешки и евентуално няколко неясни фрагмента, ако почувствате нуждата.

Ако не разпознаете код, просто го погледнете в Уикипедия, за да получите по-добро разбиране.

ErrorDocument 100 / 100_CONTINUE ErrorDocument 101 / 101_SWITCHING_PROTOCOLS ErrorDocument 102 / 102_PROCESSING ErrorDocument 200 / 200_OK ErrorDocument 201 / 201_CREATED ErrorDocument 202 / 202_ACCEPTED ErrorDocument 203 / 203_NON_AUTHORITATIVE ErrorDocument 204 / 204_NO_CONTENT ErrorDocument 205 / 205_RESET_CONTENT ErrorDocument 206 / 206_PARTIAL_CONTENT ErrorDocument 207 / 207_MULTI_STATUS ErrorDocument 300 / 300_MULTIPLE_CHOICES ErrorDocument 301 / 301_MOVED_PERMANENTLY ErrorDocument 302 / 302_MOVED_TEMPORARILY ErrorDocument 303 / 303_SEE_OTHER ErrorDocument 304 / 304_NOT_MODIFIED ErrorDocument 305 / 305_USE_PROXY ErrorDocument 307 / 307_TEMPORARY_REDIRECT ErrorDocument 400 / 400_BAD_REQUEST ErrorDocument 401 / 401_UNAUTHORIZED ErrorDocument 402 / 402_PAYMENT_REQUIRED ErrorDocument 403 / 403_FORBIDDEN ErrorDocument 404 / 404_NOT_FOUND ErrorDocument 405 / 405_METHOD_NOT_ALLOWED ErrorDocument 406 / 406_NOT_ACCEPTABLE ErrorDocument 407 / 407_PROXY_AUTHENTICATION_REQUIRED ErrorDocument 408 / 408_REQUEST_TIME_OUT ErrorDocument 409 / 409_CONFLICT ErrorDocument 410 / 410_GONE ErrorDocument 411 / 411_LENGTH_REQUIRED ErrorDocument 412 / 412_PRECONDITION_FAILED ErrorDocument 413 / 413_REQUEST_ENTITY_TOO_LARGE ErrorDocument 414 / 414_REQUEST_URI_TOO_LARGE ErrorDocument 415 / 415_UNSUPPORTED_MEDIA_TYPE ErrorDocument 416 / 416_RANGE_NOT_SATISFIABLE ErrorDocument 417 / 417_EXPECTATION_FAILED ErrorDocument 422 / 422_UNPROCESSABLE_ENTITY ErrorDocument 423 / 423_LOCKED ErrorDocument 424 / 424_FAILED_DEPENDENCY ErrorDocument 426 / 426_UPGRADE_REQUIRED ErrorDocument 500 / 500_INTERNAL_SERVER_ERROR ErrorDocument 501 / 501_NOT_IMPLEMENTED ErrorDocument 502 / 502_BAD_GATEWAY ErrorDocument 503 / 503_SERVICE_UNAVAILABLE ErrorDocument 504 / 504_GATEWAY_TIME_OUT ErrorDocument 505 / 505_VERSION_NOT_SUPPORTED ErrorDocument 506 / 506_VARIANT_ALSO_VARIES ErrorDocument 507 / 507_INSUFFICIENT_STORAGE ErrorDocument 510 / 510_NOT_EXTENDED 

Онлайн .htaccess Webapps

• Htaccess Builder
• .htaccess генератор за пренасочване
• .htaccessEditor - Създайте .htaccess файл
• Mod Rewrite Generator от GenerateIt.net

Други полезни ресурси

• .htaccess в Httpd Wiki
• Официална документация за Apache htaccess
• Попитай блога на Apache - Htaccess Archives
• Ultimate Ръководство за htaccess и mod_rewrite
• Всичко, което някога сте искали да знаете за правилата на Mod_Rewrite, но се страхувахте да питате

Заключителни мисли

Има толкова много безброй онлайн ресурси, които обсъждат .htaccess файлове. Моите свързани статии и webapps са чудесно място за започване. Но продължавайте да практикувате нови идеи и не се страхувайте тестване на кодови фрагменти. Докато имате резервен файл тогава можете да изпробвате всичко, което ви харесва и това е забавно учене.

Ако имате други идеи или предложения за .htaccess управление, моля, споделете с нас в пост-дискусионната област по-долу.