прокси

[satir]

в интерес на истината, проксиман и тнт... определено се толерира от админа на форума , има начин и ТОЙ знае това, че може да ограничи влизането през прокси сървъри

[kalahan2008]

в интерес на истината, проксиман и тнт... определено се толерира от админа на форума , има начин и ТОЙ знае това, че може да ограничи влизането през прокси сървъри

Бихте ли светнали широката публика какъв е този начин, че аз от специалисти уж знам, че това е технически невъзможно (визирам хора, занимаващи се с мрежи и сървъри)

[satir]

в интерес на истината, проксиман и тнт... определено се толерира от админа на форума , има начин и ТОЙ знае това, че може да ограничи влизането през прокси сървъри

Бихте ли светнали широката публика какъв е този начин, че аз от специалисти уж знам, че това е технически невъзможно (визирам хора, занимаващи се с мрежи и сървъри)

не е зле и да се почете малко...
ето ви една, две статии:
http://bulgaria.50webs.com/smiana-ip-anonimnost.html
http://forums.bgdev.org/index.php?showtopic=9474
http://about.hit.bg/work/anonymity.htm
е, требе и да се чете......

прочетете тук
поиграйте си с настройките за интернет кънекшъна и опитайте да влезете чрез прокси сървър в dupnica.eu , например
а как става администрирането прочетете тук : тук
и за MySQL ....
аз лично си поиграх, и влязох в лекса от поне 5 сървъра.. а в dupnica.eu тц...
edit: хем го администрират с joomla

[DrazniteL]

---

[DEKAH]

satir, аз лично не виждам др. причина за прояна на i.p. адреса, освен ако, някой не иска да разглежда "медицински сайтове". Така се постига измамно чувство за анонимност, без в деиствителност (в действителност) да има такава.

Усещам проблеми с правописа и пунктуацията колега. Мисля, че е време да посетите отново учебното заведение, в което сте получил средното си образование.

[satir]

значи, фатката е в конфигурирането на .htaccess файла...... 40% сигурност никак не е зле........
цък тук:

[satir]

След като влизането на Лютия във форума е толерирано "централно", вероятно по-важно е да се увеличи броя на посещенията (от него), а не качеството на постингите. Също така е вероятно, че и ние спомагаме за това, като се включваме с все нови и нови теми по повод "многоликия досадник". Т.е. ние сме ценни за форума като брой посещения, а не като съдържание на постингите. Хм!

дори не подозираш, колко си права тиксото брои ли брои....
много посещения - висока цена на рекламата....... злите езици споменават шест цифрена сума за покупката на форума

[kalahan2008]

злите езици споменават шест цифрена сума за покупката на форума

По-точно 700 000 лева.
http://lex.bg/bulletin/?isu=258&tp=n&id=5484
Lex.bg – уникални посещения
* Месечно: 320 хил. души
* Седмично: 75 хил. души
* Дневно: 12,5 хил. души
http://www.lex.bg/aboutus.php?page=3&lang=bg
А тук са цените на рекламата:
http://lex.bg/prom.php

[satir]

така де.....

[satir]

уф..... има толкова много за четене.....

Код за потвърждение: Избери целия код

.htaccess (hypertext access) е името по подразбиране на конфигурационен файл за Apache web-сървъри, който има въздействие в рамките на директория и нейните поддиректории. Файлът позволява задаване на специфични (различни от общите настройки) свойства  и правила за достъп. Името на файла започва с точка. По конвенция такива файлове в UNIX и производните и операционни системи се третират като скрити файлове.

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

Освен популярните му приложения, като подмяна на стандартните страници за показване на грешки, защита с пароли на определени директории и забрана на достъпа от определени IP адреси, .htaccess предлага и още много възможности.


1. Няколко основни разяснения и съвети

Незапознатите с .htaccess следвайки логиката на конвенцията за имена на файловете, често се объркват, че става въпрос за разширение на файл. .htaccess не е разширение, а име на файл. Или иначе казано не става въпрос за „file.htaccess”, а просто за „.htaccess”.

.htaccess е обикновен текстов ASCII файл, който можете да създадете с всеки текстов редактор, като „Notepad” или „SimpleText” например. За да създадете такъв файл отворете текстовия редактор и при записа задайте име на файла „.htaccess”. Ако използвате Notepad, вероятно ще получите файл с име „.htaccess.txt”. Не се учудвайте - както повечето програми на Microsoft така и Notepad държи да ви помогне (което по мое лично мнение в обикновено пречи). Просто преименувайте файла. За да има ефект, името на файлът трябва да бъде точно „.htaccess” (без кавичките разбира се).

Ако качвате файла на отдалечен сървър използвайте ASII режим.

След като файлът бъде поставен в необходимата директория на сървъра, уверете се, че има режим на достъп „RW-R--R--” (или 644), ако не - променете го с командата chmode. Това е изключително важно. Така зададения режим гарантира, че файлът е достъпен за сървъра, но не и за браузърите. В противен случай е възможно вашият .htaccess да бъде прочетен от всеки, което е сериозен пробив във сигурността, особено ако имате защитени с пароли директории (повече подробности - по късно). 

Повечето команди в .htaccess се записват на един ред. За да не се обърквате или при запис да повредите целостта на линиите, изключете опцията „word wrap” на редактора. 

.htaccess е създаден за Apache и UNIX (съответно производните на UNIX OC. Вкл. Linux). И макар, че в NT сървърите има подобно действие, не може да се разчита на пълна съвместимост. Тук ще говорим за приложението му в UNIX и UNIX-производни ОС.

.htaccess има въздействие както за директорията в която се намира така и за всички поддиректории. Тоест, ако поставите .htaccess във вашата основна директория, той ще има въздействие за целия сайт. В този случай е важно да се знае, че можете да поставите и други .htaccess файлове надолу в дървото, като те заменят напълно (не допълват, а заменят!) по-горния в дървото .htaccess. Или простото правило е „важи най-близкия по посока root .htaccess”.

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

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

Кодове на състоянията:

      Successful Client Requests
      200     OK
      201     Created
      202     Accepted
      203     Non-Authorative Information
      204     No Content
      205     Reset Content
      206     Partial Content

      Client Request Redirected
      300     Multiple Choices
      301     Moved Permanently
      302     Moved Temporarily
      303     See Other
      304     Not Modified
      305     Use Proxy

      Client Request Errors
      400     Bad Request
      401     Authorization Required
      402     Payment Required (not used yet)
      403     Forbidden
      404     Not Found
      405     Method Not Allowed
      406     Not Acceptable (encoding)
      407     Proxy Authentication Required
      408     Request Timed Out
      413     Request Entity Too Long
      414     Request URI Too Long
      415     Unsupported Media Type

      Server Errors
      500     Internal Server Error
      501     Not Implemented
      404     Gateway Timeout
      505     HTTP Version Not Supported


Нормално задаване на нестандартни страници за съобщения се прилага за грешките - група 4xx (Client Request Errors) и 5xx (Server Errors). Най-често това са:
404 - възниква, когато браузъра се обърне към несъществуваща страница,
500 - когато възникне грешка в текущо изпълнявания скрипт,
401 - при неуспешен опит за отваряне на защитена с име и парола страница,
403 - когато режима на достъп не позволява отваряне на страницата от браузър,
400 - когато HTTP заявката не отговаря на стандарта ...


За да зададете ваша страница, която да се върне на браузъра при възникване на някое от състоянията от таблицата по-горе, е необходимо да запишете в .htaccess по един ред за всеки код. Синтаксиса е:

CODE
1
ErrorDocument code /directory/filename.ext

Например:

CODE
1
ErrorDocument 404 /errors/notfound.html

Ако .htaccess е поставен в корена на „yoursite.com”, то при възникване на грешка 404 сървърът ще върне като резултат „yoursite.com/errors/notfound.html”.

По същия начин за грешка с код 500 може да запишете:

CODE
1
ErrorDocument 500 /errors/internalerror.html

Можете да давате произволни имена на вашите страници за съобщения, както и да ги поставяте на което и да е web-достъпно място на сървъра, но все пак е по-добре да ги поставите в една директория и да им дадете имена, които отговарят на значението им. Това ще ви помогне да се ориентирате след време. Наклонената черта в началото на пътя показва, че адресирането е спрямо корена „root” на вашия сайт. Обичайно решение е тези страници да се поставят в една директория под корена (например „/errors/”), която е забранена за индексиране от търсачките чрез файла „robots.txt”. Едно обичайно разположение е:

CODE
1
2
3
4
5
ErrorDocument 400 /errors/badrequest.html
ErrorDocument 401 /errors/authreqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/serverr.html

Допустимо и задаване на абсолютни URL, като:

CODE
1
ErrorDocument 404 http://theMySyte.net/errors/notfound.html

но така няма да можете да използвате готовите вече фрагменти за други ваши сайтове.

И накрая - можете да зададете HTML кода на страницата директно в .htaccess:

CODE
1
ErrorDocument 401 "<body><h1>You have to actually <b>BE</b> a <a ref="#">member</A> to view this page, Colonel!</body>"

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

Има различни механизми за защита на определени области: сървърно базирани (ASP, PHP, Perl и други) или клиент-базирани (JavaScript). Последните са достатъчно несериозни за да се спираме на тях.

Например в PHP можете да защитите страници чрез включване на подходящи HTTP хедъри („WWW-Authenticate: Basic realm=....”, „HTTP/1.0 401 Unauthorized”) и използване на суперглобалните променливи „$_SERVER['PHP_AUTH_USER']” и „$_SERVER['PHP_AUTH_PW']”. Но също така можете да използвате и възможностите, които предоставя .htaccess, като предимството е, че няма да се наложи да пишете програмен код.

Първото, което трябва да направите е да създадете файл наречен .htpasswd. Името на файла, начина на ъплоуд и режима на достъп отговаря на същите правила, както и .htaccess. За подробности се върнете в началото на урока. В този файл се записват имената и съответните им пароли (в криптиран вид) с които единствено може да се разреши web-достъп до директорията в която се намира съответния .htaccess файл. .htpasswd файлът трябва да съдържа по един ред за всеки оторизиран потребител. Синтаксиса е следния::

CODE
1
2
3
user1:password1
user2:password2
...

За криптиране на паролите може да използвате например handy-dandy tool.

От съображения за сигурност, трябва да поставите файла с паролите в директория, която не е web-достъпна.

Какво трябва да запишете в .htaccess:

CODE
1
2
3
4
5
AuthUserFile [i]usr/local/you/safedir[/i].htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user user1

Първия ред указва пълния път спрямо корена до файла с допустимите потребители, но забележете, че на последния ред е указан само user1. Това е подходящ синтаксис, ако желаете определени потребители да имат достъп до определени директории. Ако искате всички описани в посочения .htpasswd файл потребители да имат достъп до директорията, използвайте записа: „require valid-user”.

AuthName е името на защитената област. Можете да замените това име с по-подходящо според случая. Например „Restricted Area”.

AuthType е типа на използвания механизъм. В случая - Basic.


4. Разрешаване на SSI чрез htaccess

Много програмисти биха искали да използват удобствата, които предлага SSI (Server Side Includes), но не могат поради ограничение наложено от администратора на техния хостинг. Можете да промените това, чрез .htaccess, но първо се уверете, че по този начин не нарушавате правилата за ползване. Най-добре е да говорите с администратора.

CODE
1
2
3
AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes

Първата линия указва на сървъра, че страниците с разширение .shtml (Server parsed HTML) са валидни. Втората линия включва сървърния парсер за файлове с разширение .shtml. Тоест указва на сървъра, че тези файлове трябва да се проверяват за SSI команди (и съответно изпълняват). Последната линия е просто техническа подробност, но трябва да присъства.

И това е. Сега можете да използвате SSI. Не бързайте да променяте разширенията на всичките си файлове на .shtml. Просто вмъкнете като втора линя в горния код:

CODE
1
AddHandler server-parsed .html

Това ще накара сървъра да проверява и .html файловете за SSI команди. Идеята не е много добра доколкото ще доведе до допълнително излишно натоварване на сървъра, но пък ще ви спести време. А и е един вид елементарна защита, тъй като не подсказва на потребителите, че страницата съдържа SSI инструкции, които могат да станат обект на хакерски намеси. Както обикновено най-добре е да прецените сами според случая дали да използвате тази опция. Ако решите да разделите страниците на .shtml и .html, тази втора линия не ви е необходима. Ако не сте сигурни какво ще правите, добавете:

CODE
1
DirectoryIndex index.shtml index.html

Този ред задава страницата по подразбиране да бъде index.shtml, а ако такава липсва, ще се зареди index.html. Още за подразбиращата се страница ще разгледаме по-късно.


5. Блокиране на достъпа от определени IP адреси

Има хора или групи, които опитват да причинят вреди на сайта ви? - Има и решение- блокирайте достъпа им! Добавете код подобен на този (всяка команда е на отделен ред):

CODE
1
2
3
4
order allow,deny
deny from 123.45.6.7
deny from 012.34.5.
allow from all

Можете да блокирате достъпа на определен IP адрес или интервал от адреси. В горния пример е блокиран достъпа от адрес 123.45.6.7, както и от всички адреси започващи с 012.34.5. (012.34.5.0, 012.34.5.1 ...... 012.34.5.255). Втория вариянт едва ли има практическо приложение, но е допустим.

Можете още да използвате забрана за всички: deny from all. Освен IP адреси може да се използват и имена на домейни: deny from .knowhacker.com, което ще забрани достъпа от всички поддоменйни на knowhacker.com (www.knowhacker.com, virtual.knowhacker.com и т.н.).


6. Блокиране на достъпа на потребител / домейн по начина на обръщение

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

За да направите това обаче, преди всичко е необходимо да имате инсталиран модул mod_rewrite на вашия Apache сървър. По подразбиране този модул се инсталира заедно със сървъра, но все пак проверете. И така за да забраните целия трафик породен от обръщение през определен домейн, използвайте следния код:

За един домейн:

CODE
1
2
3
4
RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} badsite\.com [NC]
RewriteRule .* - [F]


За няколко домейна:

CODE
1
2
3
4
5
RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} badsite\.com [NC,OR]
RewriteCond %{HTTP_REFERER} anotherbadsite\.com [NC]
RewriteRule .* - [F]

Забележете, че точката е записана като ескейп последователност. Това е така, защото тук RewriteCond използва регулярни изрази (без символа ‘\’ точката ще има смисъл „които и да е символ”). Флагът [NC] („Non Case sensitive”) в края на израза задава да не се прави разлика между малки и големи букви. И накрая - последния ред от примера задава действието, което да се извърши при намиране на съвпадение в RewriteCond условията: „FAIL”. Тоест отговорът на сървъра ще бъде състояние 403 - Forbidden error. Разликата между двата примера е, че когато се изреждат RewriteCond, трябва да се постави флаг OR.

 << Предишна страница
Следваща страница >>

Ключови думи:
.htaccess .htpasswd AuthTypeBasic файл apache deny from all require valid-user error document грешки защитени директории web-достъп
. Блокиране на така наречените „bad bots” и „site rippers”

Какво е „bad bot”? - отговорът не е еднозначен, но общо взето за такива се смятат автоматични програми - „роботи, паяци”, които повече вредят отколкото носят популярност на сайта ви (например събирачки на e-mail адреси).

„Site ripper” е програма, която трасира вашия сайт и сваля цялото му съдържание за offline използване. И в двата случая събраната информация може да се използва както добронамерено (индексиране от търсачките например), така и за нанасяне на вреди - спам, откриване на пробиви в защитите и други. Също така и в двата случая има излишно натоварване на сървъра, което може да доведе до невъзможност за нормален достъп до сайта. Обикновено „bad bots” се блокират чрез друг специален файл - „robots.txt”, но можете да използвате и .htaccess. Въпросът е да знаете как да ги  идентифицирате.

По-долу е даден код, който блокира достъпа на познатите bad bots и site rippers. Информацията е събрана от форуми по темата и разбира се няма как да е пълна, но спокойно можете да добавите този код във вашия .htaccess файл (разбира се, ако имате mod_rewrite):

CODE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]Bots

Изброените в списъка програми ще получат като отговор „403 Forbidden”, което ще намали излишния трафик и евентуално ще ускори работата на вашия сървър. Ако отделите време да прегледате вашите лог-файлове, вероятно ще намерите какво да добавите към този списък.


8. Промяна на подразбиращата се страница

Подразбиращата се страница е тази, която се зарежда, когато изпишете като адрес в браузъра вашия домейн (mySite.com, http://mySite.com, http://www.mySite.com). Подразбираща се страница може да има и всяка директория от сайта. Вероятно сте свикнали с мисълта, че това е непременно index…., но чрез .htaccess можете лесно да зададете друга страница или последователност от страници които се търсят в зададения ред:

CODE
1
DirectoryIndex filename.html

определя ако не е зададено друго, да се зареди filename.html.

CODE
1
DirectoryIndex filename.html index.cgi index.pl default.htm

определя ако не е зададено друго, да се зареди първата намерена от изброените страници. Списъка се чете от ляво на дясно. Казаното се отнася не само за основната директория, а и за всяка друга от сайта. Например ако поставим .htaccess, който съдържа горния код в поддиректория /work и напишем в браузъра „http://www.mySite.com/work/”, то търсенето ще стане във /work и ще се зареди първата съществуваща от изброените страници.


9. Пренасочване

Всеки на когото се е налагало да променя или премества сайт без да се спира работата му се е сблъсквал с този проблем - как потребителите използващи старите адреси да се пренасочат към новите. Има различни начини: чрез включване на „http-equiv” тагове, javascript или сървърно базирани програми. Но има и по-лек начин и това е чрез .htaccess. Този начин изисква минимална допълнителна работа и съответно по-малък риск от грешки.

Чрез командата Redirect в .htaccess можем да зададем в описателен вид обръщенията към определени страници или директории да се пренасочват към други URL:

CODE
1
Redirect /olddirectory/oldfile.html http://yoursite.com/newdirectory/newfile.html

Както виждате пренасочването се състои от 3 части: командата Redirect; адресът който трябва да се пренасочи, записан като относителен спрямо корена; и пълния URL, където трябва да се пренасочи заявката. Трите части трябва да са отделени с интервал, но задължително трябва да са на един ред. Допустимо е пренасочване и на директории:

CODE
1
Redirect [i]olddirectory[/i] http://yoursite.com/newdirectory/
10. Предпазване на самия .htaccess от web-достъп

Това е особено важно, когато използвате защита с пароли на отделни части от сайта. Тогава вашия .htaccess съдържа информация за местонахождението на всеки .htpasswd файл. Ако имате некоректно настроен режим за достъп или вашия сървър не е достатъчно надежден, клиетнските браузъри може да покажат съдържанието на .htaccess файла, а от там и къде се намират .htpasswd файловете. Това разбира се е крайно разсъждение, но все пак е добре да се подсигурите с още една защита:

CODE
1
2
3
4
<Files .htaccess>
order allow,deny
deny from all
</Files>

Поставете тези редове в началото .htaccess. Това ще предпази файла от web-достъп и опита за отваряне с браузър ще доведе до грешка 403. Допълнително задайте режим за достъп до .htaccess чрез CHMOD: 644 или RW-R-R--R--.


11. Задаване на MIME типове

MIME - "Multipurpose Internet Mail Extensions" (Многоцелеви добавки към Интернет поща), обозначаващо метод за кодиране на текст и данни извън печатаемите символи от 7-битовата таблица ASCII чрез ASCII символи. Основното му предназначение е да осигури пренос на произволни данни през по-старата среда за електронна поща, откъдето идва и името му.

Какво трябва да направите за да може вашия сървър да използва подходящи драйвери за различните типове файлове, например MP3 или SWF? - просто да ги добавите като типове в .htaccess:

AddType application/x-shockwave-flash swf

AddType е команда с която се добавя MIME тип. Стрингът application е MIME типа който добавяте, а последната част е разширението на което отговаря този тип. В примера това е .swf разширение за Shockwave файлове.

По същия начин ако зададете application/octet-stream за някой тип файл, то при адресирането му ще се стартира процедура за download.


12. Предпазване от „hot linking”

„hot linking” или още известно под името „bandwidth stealing” е дирекно използване на ресурси (не html) от вашия сайт в други сайтове. Обикновено обект на такива линкове са изображения, javaScript, видео и др. Понякога това е нормално, но има случаи в които вие не бихте искали вашите файлове да се използват като част от други сайтове.

С използване на .htaccess, можете да забраните този процес. Например линковете към изображения или .css файлове да се блокират или да се пренасочват към невалидни или нарочно подправени такива. Отново ще ви е необходим инсталиран mod_rewrite. За да забраните използването на вашите .gif, .jpg, .js и .css файлове, добавете кода даден по-долу към вашия .htaccess в корена на сайта или директорията в която се намират съответните файлове:

CODE
1
2
3
4
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg|js|css)$ - [F]

Заменете „mydomain.com” с името на вашия домейн. Този код ще генерира грешка при опит за използване на посочените файлове. По-забавно за вас и тъжно за тези, които без ваше разрешение използват ресурси от сайта ви ще бъде да подмените съдържанието, което ще получат, без да се генерира грешка. Следващия код показва как може да се пренасочат всички hot-links, които използват ваши .gif и .jpg изображения към алтернативно изображение - angryman.gif:

CODE
1
2
3
4
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ http://www.mydomain.com/angryman.gif [R,L]

Не забравяйте да нагласите „mydomain.com” и „angryman.gif”!

Иначе казано - студен душ за горещите линкове


13. Предпазване от извеждане съдържанието на директории в браузъра

Обикновено сървърите са настроени така, че не позволяват разлистване на поддиректориите на сайта, но понякога може и да не са. Ако имате поддиректории с изображения или zip архиви и не желаете те да могат да се разглеждат чрез браузър, можете да се подсигурите като добавите:

CODE
1
IndexIgnore *

в .htaccess, поставен във въпросните директории. Командата забранява разлистването на всички (*) файлове от директорията.

Ако искате да скриете само определени файлове, тогава можете да ги укажете изрично:

CODE
1
IndexIgnore *.jpg *.gif *.png

Така ще скриете от листинга само изображенията от съответната директория.

Обратно, ако сървърът забранява разлистването на директориите, но вие искате това, тогава запишете:

CODE
1
Options +Indexes

Бъдете много внимателни относно съдържанието на директориите за които използвате тази опция! Както можете да поставите знак плюс пред опцията, така можете да поставите и знак минус (Options -Indexes), което ще забрани разлистването. Например в поддиректория на разрешена за разлистване директория.

Ако искате да използвате докрай възможностите за листинг на директория, можете да създадете 2 специални текстови файла: HEADER и README. При включена опция +Indexes, и обръщение на браузър към директорията, първо ще се изведе съдържанието на файла HEADER, след него листинга и накрая съдържанието на README.


14. Заключение и допълнителна информация

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

Също е добре да се запознаете с Apache User's Guide за по-детайлна информация, ако наистина имате намерение да улесните работата си като webmaster. Не е необходимо примерно да променяте ръчно хиляди страници в един голям сайт, ако можете да направите промяната с един ред в .htacces!

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




Източник: javascriptkit.com

По материали от JK Forum, JavaScriptKit.com, wikipedia.org и apache.org



[/code]

[DrazniteL]

---

[satir]

нормално е, минаваш през поне два ДНС сървъра..... адреса ти се преобразува два пъти..... ако не греша.......
не ползваш Direct Internet Connection... директ е ключовата дума
значи щом е индирект СЕ МОТА ПОВЕЧЕ.....
и понеже някаде беще питал на кой и за какво му е да се крие зад прокси хм.... питая онова говедо спамера
едит: сори за говедото ама да не разбираш че не си желан си е говежда история

[ptodorova]

прокси се е прекръстил на antivirus32
вече ни спами и с лични съобщения

[satir]

на мене не ми е писал
нека опита, такава цветна ще получи )))))))))))))))))))))))))))))))

[kalahan2008]

прокси се е прекръстил на antivirus32
вече ни спами и с лични съобщения

На мен не смее - парен каша духа

[Nekonventsialen]

Не скиваш ли че ежедневно вършат престъпления в реалния свят,но ги учиш и как да ги вършат и въввиртуалното пространство.Браво ...

[satir]

Не скиваш ли че ежедневно вършат престъпления в реалния свят,но ги учиш и как да ги вършат и въввиртуалното пространство.Браво умнико...

Ако не си разбрал "umpako", темата е как да се спре влизането през прокси!!!
http://perishablepress.com/press/2008/0 ... -htaccess/
и понеже си много принципен, очаквам публично извинение!
требе да се чете както 100пъти вече казах!!!

[satir]

сигнатури нещо, това-онова...

[Nekonventsialen]

glum...niko,i ti gi vurchi6 dosta interesni naposled,k no neise...

[satir]

и понеже темата е за ОГРАНИЧАВАНЕ влизането през прокси в сайта, аз търся начин как да стане това, а ти ме упрекваш в обратното РЕДНО Е ДА МИ СЕ ИЗВИНИШ ПУБЛИЧНО!!!
П.С. ако наистина си принципен , както искаш да изглеждаш.
или само искаш?а?А??А???
аре нема нужда! виждал съм секакви измислени герои
едит: ако знаеш начин за ограничаване сподели, не ми спами в темата иначе!