Конфигуриране на диспечера
ЗАБЕЛЕЖКА
Версиите на диспечера са независими от AEM. Може да сте били пренасочени към тази страница, ако сте следвали връзка към документацията на Dispatcher, която е вградена в документацията за предишна версия на AEM.
Следните раздели описват как да конфигурирате различни аспекти на диспечера.
Всички елементи на AEM и Dispatcher могат да бъдат инсталирани както в IPv4, така и в IPv6 мрежи. Вижте IPV4 и IPV6.
По подразбиране конфигурацията на Dispatcher се съхранява в текстовия файл dispatcher.any, въпреки че можете да промените името и местоположението на този файл по време на инсталацията.
Конфигурационният файл съдържа поредица от свойства с една стойност или много стойности, които контролират поведението на Dispatcher:
Имената на свойствата са с префикс наклонена черта /. Свойствата с много стойности включват дъщерни елементи с помощта на скоби { }.Една примерна конфигурация е структурирана по следния начин:
# име на диспечера/име "интернет-сървър"# всяка ферма конфигурира набор (балансирани на натоварване) рендери/ферми {# първи запис във ферма (етикетът не е важен, само за ваше удобство) /website { /clientheaders { # Списък на заглавки, които се предават } /virtualhosts { # Списък с URL адреси за този уеб сайт } /sessionmanagement { # настройки за потребителско удостоверяване } /renders { # Списък на AEM екземпляри, които изобразяват документите } /filter { # Списък с филтри } /vanity_urls { # List of vanity URLs } /cache { # Cache configuration /rules { # List of cachable documents } /invalidate { # List of auto-invalidated documents } } /statistics { /categories { # Категориите документи, които се използват за балансиране на натоварването оценки } } /stickyConnectionsFor "/myFolder" /health_check { # Страницата се свързва, когато екземпляр върне 500 } /retryDelay "1" /numberOfRetries "5" /unavailablePenalty "1" /failover "1" } }Можете включват други файлове, които допринасят за конфигурацията:
Ако вашият конфигурационен файл е голям, можете да го разделите на няколко по-малки файла (които са по-лесни за управление), след което да ги включите. За да включите файлове, които се генерират автоматично.Например, за да включите файла myFarm.any в /farms конфигурация използвайте следния код:
/farms{$include "myFarm.any"}Използвайте звездичката (*) като заместващ знак, за да посочите набор от файлове за включване.
Например, ако файловете farm_1.any до farm_5.any съдържат конфигурацията на ферми от едно до пет, можете да ги включите, както следва:
/farms{$include "farm_*.any"}Можете да използвате променливи на средата в свойства със стойност на низ във файла dispatcher.any вместо твърдо кодиране на стойностите. За да включите стойността на променлива на средата, използвайте формата ${variable_name}.
Например, ако файлът dispatcher.any се намира в същата директория като директорията на кеша, може да се използва следната стойност за свойството docroot:
/docroot "${PWD}/cache"Като друг пример, ако създадете променлива на средата с име PUBLISH_IP, която съхранява името на хоста на екземпляра за публикуване на AEM, може да се използва следната конфигурация на свойството /renders:
/renders {/0001 {/hostname "${PUBLISH_IP}"/port "8443"}}Използвайте свойството /name, за да посочите уникално име за идентифициране на екземпляра на Dispatcher . Свойството /name е свойство от най-високо ниво в конфигурационната структура.
Свойството /farms дефинира един или повече набори от поведения на диспечера, където всеки набор е свързан с различни уеб сайтове или URL адреси. Свойството /farms може да включва една ферма или множество ферми:
Използвайте една ферма, когато искате Dispatcher да обработва всички ваши уеб страници или уеб сайтове по един и същи начин. Създайте множество ферми, когато различни области на вашия уеб сайт или различни уеб сайтове изискват различно поведение на Dispatcher.Свойството /farms е свойство от най-високо ниво в конфигурационната структура. За да дефинирате ферма, добавете дъщерно свойство към свойството /farms. Използвайте име на свойство, което уникално идентифицира фермата в екземпляра на Dispatcher.
Свойството /farmname е с много стойности и съдържа други свойства, които определят поведението на диспечера:
URL адресите на страниците, към които се прилага фермата. Един или повече URL адреси на услуги (обикновено за екземпляри за публикуване на AEM), които да се използват за рендиране на документи. Статистическите данни, които да се използват за балансиране на натоварването на множество рендъри на документи. Няколко други поведения, като например кои файлове да се кеш и къде.Стойността може да включва всеки буквено-цифров (a-z, 0-9) знак. Следващият пример показва дефиницията на скелета за две ферми с имена /daycom и /docsdaycom:
#име на диспечера/име "day sites"#farms разделът дефинира списък от ферми или сайтове/ферми{ /daycom { ... } /docdaycom {... }}ЗАБЕЛЕЖКА
Ако използвате повече от една ферма за рендиране, списъкът се оценява отдолу нагоре. Това е особено важно, когато дефинирате виртуални хостове за вашите уебсайтове.
Всяко свойство на ферма може да съдържа следните дъщерни свойства:
ВНИМАНИЕ
Параметърът /homepage (само за IIS) вече не работи. Вместо това трябва да използвате IIS URL Rewrite Module.
Ако използвате Apache, трябва да използвате модула mod_rewrite. Вижте документацията на уеб сайта на Apache за информация относно mod_rewrite (например Apache 2.4). Когато използвате mod_rewrite, препоръчително е да използвате флага „passthrough|PT“ (преминаване към следващия манипулатор), за да принудите механизма за пренаписване да зададе uri полето на вътрешната структура request_rec на стойността на полето за име на файл.
Свойството /clientheaders дефинира списък с HTTP заглавки, които Dispatcher предава от клиентската HTTP заявка към рендерера (AEM екземпляр).
По подразбиране Dispatcher препраща стандартните HTTP заглавки към екземпляра на AEM. В някои случаи може да искате да препратите допълнителни заглавки или да премахнете конкретни заглавки:
Добавете заглавки, като персонализирани заглавки, които вашият AEM екземпляр очаква в HTTP заявката. Премахнете заглавки, като заглавки за удостоверяване, които са подходящи само за уеб сървъра.Ако персонализирате набора от заглавки, през които да преминавате, вие трябва да посочи изчерпателен списък от заглавки, включително тези, които обикновено са включени по подразбиране.
Например екземпляр на Dispatcher, който обработва заявки за активиране на страници за екземпляри за публикуване, изисква заглавката PATH в секцията /clientheaders. Заглавката PATH позволява комуникация между агента за репликация и диспечера.
Следният код е примерна конфигурация за /clientheaders:
/clientheaders{"CSRF-Token""X-Forwarded-Proto""referer""user-agent""authorization""from""content-type""content-length""accept-charset""accept-encoding"" accept-language""accept""host""if-match""if-none-match""if-range""if-unmodified-since""max-forwards""proxy-authorization""proxy-connection"" range""cookie""cq-action""cq-handle""handle""action""cqstats""depth""translate""expires""date""dav""ms-author-via""if"" lock-token""x-expected-entity-length""destination""PATH"}Свойството /virtualhosts дефинира списък с всички комбинации име на хост/URI, които Dispatcher приема за тази ферма. Можете да използвате знака звездичка (*) като заместващ знак. Стойностите за свойството / virtualhosts използват следния формат:
[scheme]host[uri][*]Следната примерна конфигурация обработва заявки за домейните .com и .ch на myCompany и всички домейни на mySubDivision:
/virtualhosts{"www.myCompany.com""www.myCompany.ch""www.mySubDivison.*"}Следната конфигурация обработва всички заявки:
/virtualhosts{"*"}Когато Dispatcher получи HTTP или HTTPS заявка, той намира стойността на виртуалния хост, която най-добре съответства на хоста, uri и схемата заглавки на искане. Dispatcher оценява стойностите в свойствата на virtualhosts в следния ред:
Dispatcher започва от най-ниската ферма и напредва нагоре във файла dispatcher.any. За всяка ферма Dispatcher започва с най-горната стойност в свойството virtualhosts и напредва надолу в списъка със стойности.Dispatcher намира най-добре съответстващата стойност на виртуалния хост по следния начин:
Използва се първият срещнат виртуален хост, който съответства и на трите хоста, схемата и uri на заявката. Ако нито една стойност на virtualhosts няма части от схема и uri, които съответстват на схемата и uri на заявката, първият срещнат използва се виртуален хост, който съответства на хоста на заявката. Ако нито една стойност на virtualhosts няма хост част, която съответства на хоста на заявката, се използва най-горният виртуален хост на най-горната ферма.Следователно трябва да поставите своя виртуален хост по подразбиране хост в горната част на свойството virtualhosts в най-горната ферма на вашия файл dispatcher.any.
Следният пример представлява фрагмент от файл dispatcher.any, който дефинира две ферми за диспетчери, като всяка ферма дефинира свойство virtualhosts.
/farms{/myProducts{/virtualhosts{"www.mycompany.com"}/renders{/hostname "server1.myCompany.com"/port "80"}}/myCompany{/virtualhosts{"www.mycompany.com/products /*"}/renders{/hostname "server2.myCompany.com"/port "80"}}}Използвайки този пример, следващата таблица показва виртуалните хостове, които са разрешени за дадените HTTP заявки:
Заявка URL Разрешен виртуален хостhttps://www.mycompany.com/products/gloves.htmlwww.mycompany.com/products/https://www.mycompany.com/about.htmlwww.mycompany.comВНИМАНИЕ
/allowAuthorized трябва да бъде зададено на "0" в секцията /cache, за да активирате тази функция.
Създайте защитена сесия за достъп до фермата за изобразяване, така че потребителите да трябва да влязат, за да имат достъп до всяка страница във фермата. След като влязат, потребителите имат достъп до страниците във фермата. Вижте Създаване на затворена потребителска група за информация относно използването на тази функция с CUG. Освен това вижте контролния списък за сигурност на диспечера, преди да стартирате на живо.
Свойството /sessionmanagement е подсвойство на /farms.
ВНИМАНИЕ
Ако секциите на вашия уебсайт използват различни изисквания за достъп, трябва да дефинирате няколко ферми.
/sessionmanagement има няколко подпараметъра:
/директория (задължително)
Директорията, която съхранява информацията за сесията. Ако директорията не съществува, тя се създава.
ВНИМАНИЕ
Когато конфигурирате подпараметъра на директорията, не сочете към главната папка (/директория "/"), тъй като може да причини сериозни проблеми. Винаги трябва да посочите пътя до папката, която съхранява информацията за сесията. Например:
/sessionmanagement{/directory "/usr/local/apache/.sessions"}/encode (по избор)
Как се кодира информацията за сесията. Използвайте md5 за криптиране с помощта на алгоритъма md5 или hex за шестнадесетично кодиране. Ако шифровате данните за сесията, потребител с достъп до файловата система не може да прочете съдържанието на сесията. По подразбиране е md5.
/заглавие (по избор)
Името на HTTP заглавката или бисквитката, която съхранява информацията за оторизация. Ако съхранявате информацията в http заглавката, използвайте HTTP:. За да съхраните информацията в бисквитка, използвайте Cookie:. Ако не посочите стойност, използва се HTTP:авторизация.
/изчакване (по избор)
Броят секунди до времето за изчакване на сесията след последното й използване. Ако не е указано, се използва "800", така че сесията изтича малко повече от 13 минути след последната заявка на потребителя.
Примерна конфигурация изглежда по следния начин:
/sessionmanagement{/directory "/usr/local/apache/.sessions"/encode "md5"/header "HTTP:authorization"/timeout "800"}/renders свойство дефинира URL адреса, към който Dispatcher изпраща заявки за изобразяване на документ. Следният примерен раздел /renders идентифицира един екземпляр на AEM за изобразяване:
/renders{/myRenderer{# име на хост или IP на програмата за изобразяване/име на хост "aem.myCompany.com"# порт на програмата за изобразяване/порт "4503"# изчакване на връзката в милисекунди, "0" (по подразбиране) чака неопределено време/изчакване "0 "}}Следният примерен раздел /renders идентифицира екземпляр на AEM, който работи на същия компютър като диспечера:
/renders{/myRenderer { /hostname "127.0.0.1" /port "4503" }}Следният пример раздел /renders разпределя заявките за изобразяване поравно между два AEM екземпляра:
/renders{/myFirstRenderer{/hostname "aem.myCompany.com"/port "4503"}/mySecondRenderer{/hostname "127.0.0.1"/port "4503"}}/изчакване
Указва времето за изчакване на връзката за достъп до екземпляра на AEM в милисекунди. По подразбиране е "0", което кара диспечера да чака за неопределено време.
/receiveTimeout
Определя времето в милисекунди, което може да отнеме отговор. По подразбиране е "600000", което кара диспечера да чака 10 минути. Настройка на "0" премахва напълно времето за изчакване.
Ако времето за изчакване е достигнато при анализиране на заглавките на отговора, се връща HTTP състояние 504 (лош шлюз). Ако времето за изчакване е достигнато, докато се чете тялото на отговора, Dispatcher ще върне непълния отговор на клиента, но ще изтрие всеки кеш файл, който може да е бил записан.
/ipv4
Указва дали Dispatcher използва функцията getaddrinfo (за IPv6) или функцията gethostbyname (за IPv4) за получаване на IP адреса на изобразяването. Стойност 0 води до използването на getaddrinfo. Стойност 1 води до използването на gethostbyname. Стойността по подразбиране е 0.
Функцията getaddrinfo връща списък с IP адреси. Диспечерът повтаря списъка с адреси, докато установи TCP/IP връзка. Следователно свойството ipv4 е важно, когато името на хоста за изобразяване е свързано с множество IP адреси и хостът, в отговор на функцията getaddrinfo, връща списък с IP адреси, които винаги са в същия ред. В тази ситуация трябва да използвате функцията gethostbyname, така че IP адресът, с който се свързва Dispatcher, да бъде рандомизиран.
Amazon Elastic Load Balancing (ELB) е такава услуга, която отговаря на getaddrinfo с потенциално същия подреден списък от IP адреси.
/сигурно
Ако свойството /secure има стойност "1", Dispatcher използва HTTPS за комуникация с екземпляра на AEM. За допълнителни подробности вижте също Конфигуриране на диспечера за използване на SSL.
/винаги-разрешаване
С Dispatcher версия 4.1.6 можете да конфигурирате свойството /always-resolve, както следва:
Когато е зададено на "1", то ще разрешава името на хоста при всяка заявка (диспечерът никога няма да кешира IP адрес). Може да има леко въздействие върху производителността поради допълнителното извикване, необходимо за получаване на информация за хоста за всяка заявка. Ако свойството не е зададено, IP адресът ще бъде кеширан по подразбиране.Също така това свойство може да се използва в случай, че срещате проблеми с динамично разрешаване на IP, както е показано в следния пример:
/renders {/0001 { /hostname "host-name-here" /port "4502" /ipv4 "1" /always-resolve "1" }}Използвайте /filter раздел за указване на HTTP заявките, които Dispatcher приема. Всички други заявки се изпращат обратно към уеб сървъра с код за грешка 404 (страницата не е намерена). Ако не съществува секция /filter, всички заявки се приемат.
Забележка: Заявките за statfile винаги се отхвърлят.
Секцията /filter се състои от поредица от правила, които или отказват, или разрешават достъп до съдържание според моделите в частта на реда за заявка на HTTP заявката. Трябва да използвате стратегия за разрешен списък за вашия /filter раздел:
Първо, откажете достъп до всичко. Разрешете достъп до съдържание, ако е необходимо.Всеки елемент в секцията /filter включва тип и модел, който съответства на конкретен елемент от заявката ред или целия ред на заявка. Всеки филтър може да съдържа следните елементи:
Тип: /type показва дали да се разреши или откаже достъп за заявките, които отговарят на модела. Стойността може да бъде разрешена или отказана.
Елемент на реда за заявка: Включете /method, /url, /query или /protocol и шаблон за филтриране на заявки според тези специфични части от частта на реда за заявка на HTTP заявката. Филтрирането на елементи от реда на заявката (вместо на целия ред на заявката) е предпочитаният метод за филтриране.
Разширени елементи на реда за заявка: Започвайки с Dispatcher 4.2.0, четири нови филтърни елемента са налични за използване. Тези нови елементи са съответно /път, /селектори, /разширение и /суфикс. Включете един или повече от тези елементи, за да контролирате допълнително URL моделите.
ЗАБЕЛЕЖКА
За повече информация относно това към коя част от реда на заявката се отнася всеки от тези елементи, вижте wiki страницата Sling URL Decomposition.
Свойство glob: Свойството /glob се използва за съвпадение с целия ред на заявка на HTTP заявката.ВНИМАНИЕ
Филтрирането с globs е отхвърлено в Dispatcher. Поради това трябва да избягвате използването на globs в секциите /filter, тъй като това може да доведе до проблеми със сигурността. И така, вместо:
/glob "* *.css *"
трябва да използвате
/url "*.css"
Частта на реда за заявка на HTTP заявкитеHTTP/1.1 дефинира реда на заявката, както следва:
Метод Заявка-URI HTTP-версия
Знаците представляват връщане на каретка, последвано от подаване на ред. Следният пример е линията за заявка, която се получава, когато клиент поиска страницата на английски на САЩ на сайта WKND:
ВЗЕМЕТЕ /content/wknd/us/en.html HTTP.1.1
Вашите шаблони трябва да вземат под внимание знаците за интервал в реда за заявка и знаците.
Двойни кавички срещу единични кавичкиКогато създавате вашите правила за филтриране, използвайте двойни кавички "шаблон" за прости модели. Ако използвате Dispatcher 4.2.0 или по-нова версия и вашият модел включва регулярен израз, трябва да оградите шаблона на регулярен израз „(шаблон1|модел2)“ в единични кавички.
Регулярни изразиВъв версии на Dispatcher, по-късни от 4.2.0, можете да включите POSIX разширени регулярни изрази във вашите шаблони за филтриране.
Отстраняване на неизправности с филтриАко вашите филтри не се задействат по начина, по който бихте очаквали, активирайте Trace Logging в диспечера, за да можете да видите кой филтър прихваща заявката.
Примерен филтър: Отказ на всичкиСледният примерен филтърен раздел кара Dispatcher да отказва заявки за всички файлове. Трябва да откажете достъп до всички файлове и след това да разрешите достъп до определени области.
/0001{ /glob "*" /type "deny" }Заявките към изрично отказана област водят до връщане на код за грешка 404 (страницата не е намерена).
Примерен филтър: Отказ на достъп до конкретни областиФилтрите ви позволяват също така да откажете достъп до различни елементи, например ASP страници и чувствителни области в публикуван екземпляр. Следният филтър отказва достъп до ASP страници:
/0002{ /type "deny" /url "*.asp"}Примерен филтър: Разрешаване на POST заявкиСледният примерен филтър позволява изпращане на данни от формуляр чрез метода POST:
/filter {/0001{ /glob "*" /type "deny" }/0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }}Примерен филтър: Разрешаване на достъп до конзолата на работния процесСледният пример показва филтър, използван за отказ на външен достъп до конзолата на работния поток:
/filter {/0001{ /glob "*" /type "deny" }/0002{/type "allow"/url "/libs/cq/workflow/content/console*"}}Ако вашият екземпляр за публикуване използва контекст на уеб приложение (например публикуване) това също може да се добави към вашата дефиниция на филтъра.
/0003 { /type "deny"/url "/publish/libs/cq/workflow/content/console/archive*"}Ако все още имате нужда от достъп до отделни страници в рамките на ограничената зона, можете да разрешите достъп до тях . Например, за да разрешите достъп до раздела Архив в рамките на конзолата на работния процес, добавете следния раздел:
/0004{ /type "allow"/url "/libs/cq/workflow/content/console/archive*"ЗАБЕЛЕЖКА
Когато към една заявка се прилагат няколко модела на филтри, последният приложен модел на филтър е ефективен.
Примерен филтър: Използване на регулярни изразиТози филтър позволява разширения в директории с непублично съдържание, използвайки регулярен израз, дефиниран тук между единични кавички:
/005{/type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }Примерен филтър: Филтриране на допълнителни елементи на URL адрес на заявкаПо-долу е пример за правило, което блокира извличане на съдържание от пътя /content и неговото поддърво, като се използват филтри за път, селектори и разширения:
/006 {/type "deny"/path "/content/*"/selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'/extension '(json|xml|html)'}Когато конфигурирате Dispatcher, трябва да ограничите външния достъп възможно най-много. Следният пример осигурява минимален достъп за външни посетители:
След като създадете филтри, тествайте достъпа до страницата, за да сте сигурни, че вашето AEM копие е защитено.
Следната секция /filter на файла dispatcher.any може да се използва като основа във вашия конфигурационен файл на Dispatcher.
Този пример се основава на конфигурационния файл по подразбиране, предоставен с Dispatcher, и е предназначен като пример за използване в производствена среда. Елементите с префикс # са деактивирани (коментирани), трябва да внимавате, ако решите да активирате някой от тях (като премахнете # на този ред), тъй като това може да има въздействие върху сигурността.
Трябва да откажете достъп до всичко, след което да разрешите достъп до конкретни (ограничени) елементи:
/filter{# Първо откажете всичко и след това разрешете конкретни записи/0001 { /type "deny" /glob "*" }# Open consoles# /0011 { /type "allow" /url "/admin/*"}# разрешите сървлета администратор на двигателя# /0012 { /type "allow" /url "/crx/*"}# разрешаване на хранилище за съдържание# /0013 { /type "allow" /url "/system/*" }# разрешаване на OSGi конзола# Разрешаване на не- директории с публично съдържание# /0021 { /type "allow" /url "/apps/*" }# разрешаване на достъп на приложения# /0022 { /type "allow" /url "/bin/*"}/0023 { /type "allow " /url "/content*" }# деактивирайте това правило, за да разрешите само картографирано съдържание# /0024 { /type "allow" /url "/libs/*" }# /0025 { /type "deny"/url "/libs /shindig/proxy*" } # ако активирате /libs затворете достъпа до прокси # /0026 { /type "allow" /url "/home/*" }# /0027 { /type "allow" /url "/tmp/ *"}# /0028 { /type "allow" /url "/var/*"}# Активиране на разширения в директории с непублично съдържание, като се използва регулярен израз/0041{/type "allow"/extension '(css|gif |ico|js|png|swf|jpe?g)'}# Активиране на функции/0062 { /type "allow" /url "/libs/cq/personalization/*"}# активиране на персонализация# Отказ за грабване на съдържание на всички достъпни страници, използвайки регулярни изрази/0081{/type "deny"/selectors '((sys|doc)view|query|[0-9-]+)'/extension '(json|xml)'}# Отказ за грабване на съдържание за /content и неговото поддърво/0082{/type "deny"/path "/content/*"/selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'/extension '(json|xml|html) '}# /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" }# разрешаване на json заявки на едно нивоЗАБЕЛЕЖКА
Филтри 0030 и 0031 относно динамични медии са приложими за AEM 6.0 и по-нови.
Разгледайте следните препоръки, ако решите да разширите достъпа:
Външният достъп до /admin винаги трябва да бъде напълно деактивиран, ако използвате CQ версия 5.4 или по-ранна версия.
Трябва да се внимава, когато се разрешава достъп до файлове в /libs. Достъпът трябва да бъде разрешен на индивидуална основа.
Откажете достъп до конфигурацията за репликация, така че да не може да бъде видяна:
/etc/replication.xml*/etc/replication.infinity.json*Отказ на достъп до обратния прокси сървър на Google Gadgets:
В зависимост от вашата инсталация може да има допълнителни ресурси в /libs, /apps или другаде, които трябва да бъдат предоставени. Можете да използвате файла access.log като един от методите за определяне на ресурси, които се осъществяват външен достъп.
ВНИМАНИЕ
Достъпът до конзоли и директории може да представлява риск за сигурността на производствените среди. Освен ако нямате изрични обосновки, те трябва да останат деактивирани (коментирани).
От версия 4.1.5 на Dispatcher използвайте секцията /filter, за да ограничите низовете на заявки. Силно препоръчително е изрично да разрешите низове на заявки и да изключите общо разрешение чрез позволяващи филтърни елементи.
Един запис може да има glob или комбинация от метод, url, заявка и версия, но не и двете. Следният пример разрешава низа на заявка a=* и отказва всички други низове на заявка за URL адреси, които преобразуват към възела /etc:
/filter { /0001 { /type "deny" /method "POST" /url "/etc/*" } /0002 { /type "allow" /method "GET" /url "/etc/*" /query "a =*" }}ЗАБЕЛЕЖКА
Ако дадено правило съдържа /query, то ще съответства само на заявки, които съдържат низ на заявка и отговарят на предоставения образец на заявка.
В примера по-горе, ако трябва да бъдат разрешени и заявки към /etc, които нямат низ за заявка, ще са необходими следните правила:
/filter {>/0001 { /type "deny" /method “*" /url "/path/*" }>/0002 { /type "allow" /method "GET" /url "/path/*" }>/0003 { /type “deny” /method "GET" /url "/path/*" /query "*" }>/0004 { /type "allow" /method "GET" /url "/path /*" /query "a=*" }}Филтрите на Dispatcher трябва да блокират достъпа до следните страници и скриптове на екземпляри за публикуване на AEM. Използвайте уеб браузър, за да се опитате да отворите следните страници, както би направил посетител на сайта, и проверете дали се връща код 404. Ако се получи някакъв друг резултат, коригирайте филтрите си.
Имайте предвид, че трябва да видите нормално изобразяване на страницата за /content/add_valid_page.html?debug=layout.
/admin/system/console/dav/crx.default/crx/bin/crxde/logs/jcr:system/jcr:versionStorage.json/_jcr_system/_jcr_versionStorage.json/libs/wcm/core/content/siteadmin.html/libs /collab/core/content/admin.html/libs/cq/ui/content/dumplibs.html/var/linkchecker.html/etc/linkchecker.html/home/users/a/admin/profile.json/home/users /a/admin/profile.xml/libs/cq/core/content/login.json/content/../libs/foundation/components/text/text.jsp/content/.{.}/libs/foundation/components /text/text.jsp/apps/sling/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config/jcr%3acontent/jcr%3adata/libs/foundation/components/primary/cq/workflow/components /participants/json.GET.servlet/content.pages.json/content.languages.json/content.blueprint.json/content.-1.json/content.10.json/content.infinity.json/content.tidy. json/content.tidy.-1.blubber.json/content/dam.tidy.-100.json/content/content/geometrixx.sitemap.txt /content/add_valid_page.query.json?statement=//*/content/ add_valid_page.qu%65ry.js%6Fn?statement=//*/content/add_valid_page.query.json?statement=//*[@transportPassword]/(@transportPassword%20|%20@transportUri%20|%20@ transportUser)/content/add_valid_path_to_a_page/_jcr_content.json/content/add_valid_path_to_a_page/jcr:content.json/content/add_valid_path_to_a_page/_jcr_content.feed/content/add_valid_path_to_a_page/jcr:content.feed/content/ add_valid_path_to_a_page/pagename._jcr_content.feed/content /add_valid_path_to_a_page/pagename.jcr:content.feed/content/add_valid_path_to_a_page/pagename.docview.xml/content/add_valid_path_to_a_page/pagename.docview.json/content/add_valid_path_to_a_page/pagename.sysview.xml/etc.xml/content .feed.xml /content.rss.xml/content.feed.html/content/add_valid_page.html?debug=layout/projects/tagging/etc/replication.html/etc/cloudservices.html/welcomeИздайте следната команда в терминал или команден ред, за да определите дали анонимният достъп за запис е разрешен. Не трябва да можете да записвате данни в възела.
curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"
Издайте следната команда в терминал или команден ред, за да се опитате да обезсилите кеша на Dispatcher и се уверете, че получавате отговор с код 404:
curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache
Конфигурирайте Dispatcher, за да активирате достъп до специални URL адреси, които са конфигурирани за вашите AEM страници.
Когато достъпът до специални URL адреси е активиран, Dispatcher периодично извиква услуга, която се изпълнява на екземпляра за изобразяване, за да получи списък с допълнителни URL адреси. Dispatcher съхранява този списък в локален файл. Когато заявка за страница бъде отказана поради филтър в секцията /filter, Dispatcher се консултира със списъка с точни URL адреси. Ако отказаният URL адрес е в списъка, Dispatcher разрешава достъп до ненужния URL адрес.
За да разрешите достъп до URL адреси с добавени URL адреси, добавете секция /vanity_urls към секцията /farms, подобно на следния пример:
/vanity_urls {/url "/libs/granite/dispatcher/content/vanityUrls.html"/file "/tmp/vanity_urls"/delay 300Секцията /vanity_urls съдържа следните свойства:
/url: Пътят до услугата за URL адрес, която се изпълнява на екземпляра за изобразяване. Стойността на това свойство трябва да бъде "/libs/granite/dispatcher/content/vanityUrls.html".
/file: Пътят до локалния файл, където Dispatcher съхранява списъка с точни URL адреси. Уверете се, че Dispatcher има достъп за запис до този файл.
/закъснение: (Секунди) Времето между извикванията към услугата за URL адрес.
Използвайте следната процедура, за да активирате достъпа до специални URL адреси.
Ако вашата услуга за рендиране е екземпляр на AEM, инсталирайте пакета com.adobe.granite.dispatcher.vanityurl.content на екземпляра за публикуване (вижте бележката по-горе). За всеки URL адрес, който сте конфигурирали за AEM или CQ страница, се уверете, че че конфигурацията /filter отказва URL адреса. Ако е необходимо, добавете филтър, който отказва URL адреса. Добавете секцията /vanity_urls под /farms. Рестартирайте уеб сървъра на Apache.Заявките за синдикиране обикновено са предназначени само за диспечера, така че по подразбиране те не се изпращат до програмата за изобразяване (например екземпляр на AEM).
Ако е необходимо, задайте свойството /propagateSyndPost на "1", за да препращате заявки за синдикиране към Dispatcher. Ако е зададено, трябва да се уверите, че POST заявките не са отказани в раздела за филтър.
Секцията /cache контролира как Dispatcher кешира документи. Конфигурирайте няколко подсвойства, за да приложите вашите стратегии за кеширане:
/docroot/statfile/serveStaleOnError/allowAuthorized/rules/statfileslevel/invalidate/invalidateHandler/allowedClients/ignoreUrlParams/headers/mode/gracePeriod/enableTTLПримерен кеш раздел може да изглежда по следния начин:
/cache{/docroot "/opt/dispatcher/cache"/statfile"/tmp/dispatcher-website.stat"/allowAuthorized "0"/rules{# Списък с файлове, които са кеширани}/invalidate{# Списък с файлове, които са auto-invalidated}}Свойството /docroot идентифицира директорията, където се съхраняват кешираните файлове.
ЗАБЕЛЕЖКА
Стойността трябва да бъде точно същият път като корена на документа на уеб сървъра, така че Dispatcher и уеб сървърът да обработват едни и същи файлове. Уеб сървърът е отговорен за доставянето на правилния код на състоянието, когато се използва кеш файлът на диспечера, затова е важно и то да го намери.
Ако използвате няколко ферми, всяка ферма трябва да използва различен корен на документа.
Свойството /statfile идентифицира файла, който да се използва като statfile. Dispatcher използва този файл, за да регистрира часа на най-новата актуализация на съдържанието. Статфайлът може да бъде всеки файл на уеб сървъра.
Статфайлът няма съдържание. Когато съдържанието се актуализира, Dispatcher актуализира клеймото за време. Статфайлът по подразбиране се нарича .stat и се съхранява в docroot. Диспечерът блокира достъпа до statfile.
ЗАБЕЛЕЖКА
Ако /statfileslevel е конфигуриран, Dispatcher игнорира свойството /statfile и използва .stat като име.
Свойството /serveStaleOnError контролира дали Dispatcher връща невалидни документи, когато сървърът за изобразяване върне грешка. По подразбиране, когато statfile бъде докоснат и анулира кешираното съдържание, Dispatcher изтрива кешираното съдържание следващия път, когато бъде поискано.
Ако /serveStaleOnError е зададено на "1", Dispatcher не изтрива невалидно съдържание от кеша, освен ако сървърът за изобразяване не върне успешен отговор. Отговор 5xx от AEM или изтичане на времето за изчакване на връзката кара Dispatcher да обслужва остарялото съдържание и да отговаря с HTTP статус 111 (препотвърждаването не е успешно).
Свойството /allowAuthorized контролира дали заявките, които съдържат някоя от следните удостоверяващи данни, се кешират:
Заглавката за упълномощаванеA бисквитка с име authorizationA бисквитка с име login-tokenПо подразбиране заявките, които включват тази информация за удостоверяване, не се кешират, тъй като удостоверяването не се извършва, когато кеширан документ се връща на клиента. Тази конфигурация не позволява на Dispatcher да обслужва кеширани документи на потребители, които нямат необходимите права.
Въпреки това, ако вашите изисквания позволяват кеширане на удостоверени документи, задайте /allowAuthorized на едно:
/allowAuthorized "1"
ЗАБЕЛЕЖКА
За да активирате управлението на сесии (чрез свойството /sessionmanagement), свойството /allowAuthorized трябва да бъде зададено на "0".
Свойството /rules контролира кои документи да се кешират според пътя на документа. Независимо от свойството /rules, Dispatcher никога не кешира документ при следните обстоятелства:
Ако URI на заявката съдържа въпросителен знак (?).
Това обикновено показва динамична страница, като например резултат от търсене, който не трябва да се кешира.Разширението на файла липсва.
Уеб сървърът се нуждае от разширението, за да определи типа на документа (типа MIME).Заглавката за удостоверяване е зададена (това може да се конфигурира).
Ако AEM екземплярът отговори със следните заглавки:
no-cacheno-storemust-revalidateЗАБЕЛЕЖКА
Методите GET или HEAD (за HTTP заглавката) могат да се кешират от диспечера. За допълнителна информация относно кеширането на заглавки на отговор вижте раздела Кеширане на заглавки на HTTP отговор.
Всеки елемент в свойството /rules включва глобален модел и тип:
Глобният шаблон се използва за съпоставяне на пътя на документа. Типът показва дали да се кешират документите, които съответстват на глобалния шаблон. Стойността може да бъде или разрешаване (за кеширане на документа) или отказ (за винаги изобразяване на документа).Ако нямате динамични страници (освен тези, които вече са изключени от горните правила), можете да конфигурирате Dispatcher да кешира всичко . Разделът с правила за това изглежда по следния начин:
/rules{/0000{/glob "*" /type "allow" }}За информация относно глобалните свойства вижте Проектиране на шаблони за глобални свойства.
Ако има някои секции от вашата страница, които са динамични (например приложение за новини) или в рамките на затворена потребителска група, можете да дефинирате изключения:
ЗАБЕЛЕЖКА
Затворените потребителски групи не трябва да се кешират, тъй като потребителските права не се проверяват за кеширани страници.
/rules{ /0000{ /glob "*" /type "allow" } /0001{ /glob "/en/news/*" /type "deny" } /0002{ /glob "*/private/*" /type "deny"}}Компресиране
В уеб сървърите на Apache можете да компресирате кешираните документи. Компресирането позволява на Apache да върне документа в компресиран вид, ако клиентът го поиска. Компресията се извършва автоматично чрез активиране на модула Apache mod_deflate, например:
AddOutputFilterByType DEFLATE text/plainМодулът е инсталиран по подразбиране с Apache 2.x.
Използвайте свойството /statfileslevel, за да обезсилите кешираните файлове според техния път:
Dispatcher създава .stat файлове във всяка папка от папката docroot до нивото, което посочите. Папката docroot е ниво 0.
Файловете се анулират чрез докосване на .stat файла. Датата на последната модификация на файла .stat се сравнява с датата на последната модификация на кеширан документ. Документът се извлича повторно, ако .stat файлът е по-нов.
Когато файл, намиращ се на определено ниво, е невалиден, всички .stat файлове от docroot до нивото на невалидния файл или конфигурирания statsfilevel (което от двете е по-малко) ще бъдат докоснати.
Например: ако зададете свойството statfileslevel на 6 и даден файл е невалиден на ниво 5, тогава всеки .stat файл от docroot до 5 ще бъде докоснат. Продължавайки с този пример, ако даден файл е невалиден на ниво 7, тогава всеки . stat файл от docroot до 6 ще бъде докоснат (тъй като /statfileslevel = "6").Засегнати са само ресурси по пътя до невалидния файл. Помислете за следния пример: уебсайт използва структурата /content/myWebsite/xx/. Ако зададете statfileslevel като 3, .statfile се създава, както следва:
docroot/content/content/myWebsite/content/myWebsite/*xx*Когато файл в /content/myWebsite/xx е невалиден, тогава се докосва всеки .stat файл от docroot до /content/myWebsite/xxis. Това би било така само за /content/myWebsite/xx, а не например /content/myWebsite/yy или /content/anotherWebSite.
ЗАБЕЛЕЖКА
Невалидността може да бъде предотвратена чрез изпращане на допълнителен хедър CQ-Action-Scope:ResourceOnly. Това може да се използва за изчистване на определени ресурси, без да обезсилва други части на кеша. Вижте тази страница и Ръчно обезсилване на кеша на диспетчера за допълнителни подробности.
ЗАБЕЛЕЖКА
Ако посочите стойност за свойството /statfileslevel, свойството /statfile се игнорира.
Свойството /invalidate дефинира документите, които автоматично се обезсилват, когато съдържанието се актуализира.
С автоматичното обезсилване, Dispatcher не изтрива кешираните файлове след актуализация на съдържанието, но проверява тяхната валидност, когато бъдат следващо поискани. Документите в кеша, които не са автоматично невалидни, ще останат в кеша, докато актуализацията на съдържанието изрично не ги изтрие.
Автоматичното обезсилване обикновено се използва за HTML страници. HTML страниците често съдържат връзки към други страници, което затруднява определянето дали актуализацията на съдържанието засяга дадена страница. За да сте сигурни, че всички подходящи страници са невалидни, когато съдържанието се актуализира, автоматично обезсилете всички HTML страници. Следната конфигурация прави невалидни всички HTML страници:
/invalidate{ /0000{ /glob "*" /type "deny" } /0001{ /glob "*.html" /type "allow" }}За информация относно glob свойства вижте Проектиране на шаблони за glob свойства.
Тази конфигурация предизвиква следната дейност, когато /content/wknd/us/en е активиран:
Всички файлове с шаблон en.* се премахват от папката /content/wknd/us. Папката /content/wknd/us/en./_jcr_content се премахва. Всички останали файлове, които съответстват на конфигурацията /invalidate, не се изтриват веднага . Тези файлове се изтриват при следваща заявка. В нашия пример /content/wknd.html не се изтрива, той ще бъде изтрит, когато се поиска /content/wknd.html.Ако предлагате автоматично генерирани PDF и ZIP файлове за изтегляне, може да се наложи автоматично да ги обезсилите като добре. Пример за конфигурация изглежда по следния начин:
/invalidate{ /0000 { /glob "*" /type "deny" } /0001 { /glob "*.html" /type "allow" } /0002 { /glob "*.zip" /type "allow" } / 0003 { /glob "*.pdf" /type "allow" }}Интеграцията на AEM с Adobe Analytics доставя конфигурационни данни във файл analytics.sitecatalyst.js във вашия уебсайт. Примерният файл dispatcher.any, предоставен с Dispatcher, включва следното правило за невалидност за този файл:
{ /glob "*/analytics.sitecatalyst.js"/type "allow"}Свойството /invalidateHandler ви позволява да дефинирате скрипт, който се извиква за всяка получена заявка за анулиране от Диспечер.
Извиква се със следните аргументи:
Handle - Пътят на съдържанието, който е invalidatedAction - Действието на репликация (напр. Активиране, Дезактивиране) Обхват на действието - Обхват на действието на репликация (празно, освен ако не е изпратено заглавие на CQ-Action-Scope: ResourceOnly, вижте Невалидност на кеширани страници от AEM за подробности )Това може да се използва за покриване на редица различни случаи на употреба, като например обезсилване на други специфични за приложения кешове или за справяне със случаи, когато външният URL адрес на страница и нейното място в docroot не съвпада с пътя на съдържанието.
Примерният скрипт по-долу регистрира всяка невалидна заявка във файл.
/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"примерен скрипт за обработка на невалидност#!/bin/bashprintf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.logСвойството /allowedClients дефинира конкретни клиенти, на които е разрешено да изчистват кеша. Глобиращите модели се съпоставят с IP.
Следният пример:
отказва достъп до всеки клиент изрично разрешава достъп до localhost/allowedClients{ /0001 { /glob "*.*.*.*"/type "deny" } /0002 { /glob "127.0.0.1" /type "allow" }}За информация относно глобалните свойства вижте Проектиране на шаблони за глобални свойства.
ВНИМАНИЕ
Препоръчително е да дефинирате /allowedClients.
Ако това не е направено, всеки клиент може да отправи повикване за изчистване на кеша; ако това се прави многократно, това може сериозно да повлияе на ефективността на сайта.
Секцията ignoreUrlParams определя кои URL параметри се игнорират, когато се определя дали дадена страница е кеширана или доставена от кеша:
Когато URL адрес на заявка съдържа параметри, които всички са игнорирани, страницата се кешира. Когато URL адрес на заявка съдържа един или повече параметри, които не се игнорират, страницата не се кешира.Когато параметър е игнориран за страница, страницата се кешира при първото заявяване на страницата. Следващите заявки за страницата се обслужват на кешираната страница, независимо от стойността на параметъра в заявката.
За да посочите кои параметри се игнорират, добавете глобални правила към свойството ignoreUrlParams:
За да игнорирате параметър, създайте глобално свойство, което позволява параметъра. За да предотвратите кеширането на страницата, създайте глобално свойство, което отказва параметъра.Следният пример кара Dispatcher да игнорира параметъра q, така че URL адресите на заявка, които включват параметъра q са кеширани:
/ignoreUrlParams{/0001 { /glob "*" /type "deny" }/0002 { /glob "q" /type "allow" }}С помощта на примерната стойност ignoreUrlParams следната HTTP заявка кара страницата да бъде кеширано, защото параметърът q е игнориран:
GET /mypage.html?q=5Използвайки примерната стойност ignoreUrlParams, следната HTTP заявка кара страницата да не се кешира, тъй като параметърът p не се игнорира:
GET /mypage.html?q=5&p=4За информация относно глобалните свойства вижте Проектиране на шаблони за глобални свойства.
ЗАБЕЛЕЖКА
Тази функция е налична с версия 4.1.11 на Dispatcher.
Свойството /headers ви позволява да дефинирате типовете HTTP заглавки, които ще бъдат кеширани от диспечера. При първата заявка към некеширан ресурс, всички заглавки, съответстващи на една от конфигурираните стойности (вижте примерната конфигурация по-долу), се съхраняват в отделен файл до файла на кеша. При последващи заявки към кеширания ресурс съхранените заглавки се добавят към отговора.
По-долу е представен пример от конфигурацията по подразбиране:
/cache {.../headers {"Cache-Control""Content-Disposition""Content-Type""Expires""Last-Modified""X-Content-Type-Options""Last-Modified"}}ЗАБЕЛЕЖКА
Ако имате нужда от Dispatcher, за да съхранява и доставя заглавки на отговор на ETag от AEM, направете следното:
Добавете името на заглавката в /cache/headerssection. Добавете следната директива Apache в секцията, свързана с Dispatcher:FileETag noneСвойството на режима указва какви разрешения за файлове се прилагат към новите директории и файлове в кеша. Тази настройка е ограничена от umask на процеса на извикване. Това е осмично число, съставено от сумата на една или повече от следните стойности:
0400 Разрешаване на четене от собственик.0200 Разрешаване на запис от собственик.0100 Разрешаване на собственика да търси в директории.0040 Разрешаване на четене от членове на група.0020 Разрешаване на писане от членове на група.0010 Разрешаване на членове на групата да търсят в директорията.0004 Разрешаване на четене от други .0002 Разрешаване на писане от други.0001 Разрешаване на други да търсят в директорията.Стойността по подразбиране е 0755, която позволява на собственика да чете, пише или търси, а на групата и другите да четат или търсят.
Със свойството /invalidate по подразбиране, всяко активиране на практика обезсилва всички .html файлове (когато пътят им съвпада със секцията /invalidate). На уебсайт със значителен трафик многократните последващи активации ще увеличат натоварването на процесора в задната част. При такъв сценарий би било желателно да се „забави“ .stat файлът с докосване, за да поддържа уебсайта отзивчив. Можете да направите това, като използвате свойството /gracePeriod.
Свойството /gracePeriod дефинира броя секунди, в които остарял, автоматично невалиден ресурс може да бъде обслужван от кеша след последното активиране. Свойството може да се използва в настройка, при която в противен случай пакет от активации многократно би обезсилил целия кеш. Препоръчителната стойност е 2 секунди.
За допълнителни подробности прочетете също секциите /invalidate и /statfileslevelels по-горе.
Ако е зададено, свойството /enableTTL ще оценява заглавките на отговора от бекенда и ако те съдържат максимална възраст на Cache-Control или дата на изтичане, създава се спомагателен, празен файл до кеш файла с време за модификация, равно на датата на изтичане. Когато кешираният файл бъде поискан след времето за модификация, той автоматично се изисква отново от бекенда.
ЗАБЕЛЕЖКА
Тази функция е налична във версия 4.1.11 или по-нова на Dispatcher.
Секцията /statistics дефинира категории файлове, за които Dispatcher оценява отзивчивостта на всяко изобразяване. Диспечерът използва резултатите, за да определи към кой рендер да изпрати заявка.
Всяка категория, която създавате, определя глобален модел. Диспечерът сравнява URI на заявеното съдържание с тези модели, за да определи категорията на исканото съдържание:
Редът на категориите определя реда, в който те се сравняват с URI. Първият модел на категория, който съответства на URI, е категорията на файла. Не се оценяват повече модели на категории.Dispatcher поддържа максимум 8 статистически категории. Ако дефинирате повече от 8 категории, се използват само първите 8.
Рендиране на селекция
Всеки път, когато Dispatcher изисква изобразена страница, той използва следния алгоритъм, за да избере изобразяването:
Ако заявката съдържа името на рендиране в рендерирана бисквитка, Dispatcher използва това рендиране.
Ако заявката не включва бисквитка за изобразяване, Dispatcher сравнява статистическите данни за изобразяване:
Dispatcher определя категорията на URI на заявката. Dispatcher определя кое изобразяване има най-нисък резултат за отговор за тази категория и избира това изобразяване.Ако все още не е избрано изобразяване, използвайте първото изобразяване в списъка.
Резултатът за категорията на изобразяване се основава на предишни времена за реакция, както и на предишни неуспешни и успешни връзки, които Dispatcher опитва. За всеки опит резултатът за категорията на искания URI се актуализира.
ЗАБЕЛЕЖКА
Ако не използвате балансиране на натоварването, можете да пропуснете този раздел.
Дефинирайте категория за всеки тип документ, за който искате да съхранявате статистика за избор на изобразяване. Секцията /statistics съдържа секция /categories. За да дефинирате категория, добавете ред под раздела /categories, който има следния формат:
/име { /glob "модел"}
Името на категорията трябва да е уникално за фермата. Моделът е описан в раздела Проектиране на шаблони за свойства на glob.
За да определи категорията на URI, Dispatcher сравнява URI с всеки модел на категория, докато се намери съвпадение. Диспечерът започва с първата категория в списъка и продължава по ред. Затова първо поставете категории с по-конкретни модели.
Например, Dispatcher, файлът по подразбиране dispatcher.any дефинира HTML категория и друга категория. Категорията HTML е по-специфична и затова се появява първа:
/statistics{/categories{/html { /glob "*.html" }/others{ /glob "*" }}}Следният пример също така включва категория за страници за търсене:
/statistics{/categories{/search { /glob "*search.html" }/html { /glob "*.html" }/others{ /glob "*" }}}Свойството /unavailablePenalty задава времето (в десети от секундата), което се прилага към статистиката за изобразяване, когато връзката с изобразяването е неуспешна. Диспечерът добавя времето към категорията на статистиката, което съответства на заявения URI.
Например, наказанието се прилага, когато TCP/IP връзката към определеното име на хост/порт не може да бъде установена или защото AEM не работи (и не слуша), или поради проблем, свързан с мрежата.
Свойството /unavailablePenalty е директно дъщерно на секцията /farm (брат на секцията /statistics).
Ако не съществува свойство /unavailablePenalty, се използва стойност „1“.
/unavailablePenalty "1"Свойството /stickyConnectionsFor дефинира една папка, която съдържа лепкави документи; това ще бъде достъпно чрез URL адреса. Диспечерът изпраща всички заявки от един потребител, които са в тази папка, до един и същ екземпляр за рендиране. Залепващите връзки гарантират, че данните за сесията са налични и последователни за всички документи. Този механизъм използва бисквитката за рендериране.
Следният пример дефинира лепкава връзка към папката /products:
/stickyConnectionsFor "/products"Когато една страница е съставена от съдържание от няколко възела на съдържание, включете свойството /paths, което изброява пътищата до съдържанието. Например страница съдържа съдържание от /content/image, /content/video и /var/files/pdfs. Следната конфигурация позволява лепкави връзки за цялото съдържание на страницата:
/stickyConnections {/paths {"/content/image""/content/video""/var/files/pdfs"}}Когато лепкавите връзки са активирани, модулът за диспечер задава рендерирана бисквитка. Тази бисквитка няма httponly флаг, който трябва да се добави, за да се подобри сигурността. Можете да направите това, като зададете свойството httpOnly във възела /stickyConnections на конфигурационен файл dispatcher.any. Стойността на свойството (0 или 1) определя дали бисквитката за рендериране има добавен атрибут HttpOnly. Стойността по подразбиране е 0, което означава, че атрибутът няма да бъде добавен.
За допълнителна информация относно httponly флага прочетете тази страница.
Когато лепкавите връзки са активирани, модулът на диспечера задава бисквитката за рендериране. Тази бисквитка няма флаг за сигурност, който трябва да се добави, за да се подобри сигурността. Можете да направите това, като зададете защитеното свойство във възела /stickyConnections на конфигурационен файл dispatcher.any. Стойността на свойството (0 или 1) определя дали бисквитката за изобразяване има добавен защитен атрибут. Стойността по подразбиране е 0, което означава, че атрибутът ще бъде добавен, ако входящата заявка е защитена. Ако стойността е зададена на 1, тогава флагът за сигурност ще бъде добавен независимо от това дали входящата заявка е защитена или не.
Конфигуриране на поведението на диспечера, когато сървърът за изобразяване върне грешка 500 или е недостъпен.
Използвайте свойството /health_check, за да посочите URL адрес, който се проверява, когато се появи код за състояние 500. Ако тази страница също така върне код за състояние 500, екземплярът се счита за недостъпен и конфигурируемо наказание за време ( /unavailablePenalty) се прилага към изобразяването преди повторен опит.
/health_check{# Страницата се свързва, когато екземплярът върне 500/url "/health_check.html"}Свойството /retryDelay задава времето (в секунди), което Dispatcher изчаква между кръговете на опитите за свързване с рендерите на фермата. За всеки кръг максималният брой пъти, в които Dispatcher се опитва да се свърже с рендиране, е броят рендери във фермата.
Диспетчерът използва стойност "1", ако /retryDelay не е изрично дефинирано. Стойността по подразбиране е подходяща в повечето случаи.
/retryDelay "1"Свойството /numberOfRetries задава максималния брой кръгове опити за свързване, които Dispatcher извършва с изобразяванията. Ако Dispatcher не може да се свърже успешно с рендиране след този брой повторни опити, Dispatcher връща неуспешен отговор.
За всеки кръг максималният брой пъти, в които Dispatcher се опитва да се свърже с изобразяване, е броят на изобразяванията във фермата. Следователно максималният брой пъти, които Dispatcher прави опити за свързване, е (/numberOfRetries) x (броят рендери).
Ако стойността не е изрично дефинирана, стойността по подразбиране е 5.
/numberOfRetries "5"Активирайте механизма за преодоляване при срив във вашата група Dispatcher за повторно изпращане на заявки към различни рендери, когато оригиналната заявка е неуспешна. Когато преодоляването при срив е активирано, Dispatcher има следното поведение:
Когато заявка към изобразяване върне HTTP статус 503 (НЕДОСТЪПЕН), Dispatcher изпраща заявката към различен рендер. Когато заявка към изобразяване върне HTTP статус 50x (различен от 503), Dispatcher изпраща заявка за страницата, която е конфигурирана за свойството health_check. Ако проверката на изправността върне 500 (INTERNAL_SERVER_ERROR), Dispatcher изпраща оригиналната заявка към друго изобразяване. Ако проверката на healtch върне HTTP статус 200, Dispatcher връща първоначалната грешка HTTP 500 на клиента.За да активирате преодоляване при срив , добавете следния ред към фермата (или уебсайта):
/failover "1"ЗАБЕЛЕЖКА
За да опитате отново HTTP заявки, които съдържат тяло, Dispatcher изпраща Expect: 100-continue заглавка на заявка към изобразяването, преди да спулира действителното съдържание. CQ 5.5 с CQSE веднага отговаря или със 100 (ПРОДЪЛЖИ), или с код за грешка. Други контейнери за сервлети също трябва да поддържат това.
ВНИМАНИЕ
Тази опция обикновено не е необходима. Трябва да използвате това само когато видите следните съобщения в журнала:
Грешка при четене на отговора: Прекъснато системно повикване
Всяко системно повикване, ориентирано към файловата система, може да бъде прекъснато EINTR, ако обектът на системното извикване се намира на отдалечена система, достъпна чрез NFS. Дали тези системни повиквания могат да изтекат или да бъдат прекъснати зависи от това как основната файлова система е била монтирана на локалната машина.
Използвайте параметъра /ignoreEINTR, ако вашето копие има такава конфигурация и регистрационният файл съдържа следното съобщение:
Грешка при четене на отговора: Прекъснато системно повикване
Вътрешно Dispatcher чете отговора от отдалечения сървър (т.е. AEM) с помощта на цикъл, който може да бъде представен като:
докато (отговорът не е завършен) {прочетете повече данни}Такива съобщения могат да бъдат генерирани, когато EINTR се появи в секцията „прочетете повече данни“ и са причинени от приемането на сигнал преди да бъдат получени каквито и да било данни.
За да игнорирате такива прекъсвания, можете да добавите следния параметър към dispatcher.any (преди /farms):
/ignoreEINTR "1"
Задаването на /ignoreEINTR на "1" кара Dispatcher да продължи да се опитва да чете данни, докато не бъде прочетен пълният отговор. Стойността по подразбиране е 0 и деактивира опцията.
Няколко секции в конфигурационния файл на Dispatcher използват глобални свойства като критерии за избор на клиентски заявки. Стойностите на глобалните свойства са модели, които Dispatcher сравнява с аспект на заявката, като пътя на заявения ресурс или IP адреса на клиента. Например елементите в секцията /filter използват глобални модели, за да идентифицират пътищата на страниците, върху които Dispatcher действа или отхвърля.
Глобалните стойности могат да включват заместващи знаци и буквено-цифрови знаци за определяне на шаблона.
Wildcard characterDescriptionExamples*Съвпада с нула или повече последователни екземпляри на всеки знак в низа. Крайният символ на съвпадението се определя от една от следните ситуации: Символ в низа съвпада със следващия знак в шаблона и символът на шаблона има следните характеристики: Не е *Не е ?A буквален знак (включително интервал ) или клас на знаци. Краят на шаблона е достигнат. Вътре в клас на знаци знакът се интерпретира буквално.*/geo* Съвпада с всяка страница под възела /content/geometrixx и възела /content/geometrixx-outdoors. Следните HTTP заявки съответстват на глобалния модел: "GET /content/geometrixx/en.html""GET /content/geometrixx-outdoors/en.html"*outdoors/* Съвпада с всяка страница под възела /content/geometrixx-outdoors. Например следната HTTP заявка съответства на глобалния модел: "GET /content/geometrixx-outdoors/en.html"? Съвпада с всеки отделен знак. Използвайте външни класове за знаци. Вътре в символен клас този символ се тълкува буквално.*outdoors/??/* Съвпада със страниците за всеки език в сайта geometrixx-outdoors. Например следната HTTP заявка съответства на глобалния шаблон: „GET /content/geometrixx-outdoors/en/men.html“ Следната заявка не съответства на глобалния модел: „GET /content/geometrixx-outdoors/en.html“ [ и ]Отбелязва началото и края на клас символи. Класовете знаци могат да включват един или повече диапазони от знаци и единични знаци. Съвпадение възниква, ако целевият знак съвпада с някой от знаците в класа на знаци или в рамките на определен диапазон. Ако затварящата скоба не е включена, шаблонът не създава съвпадения. *[o]men.html* Съвпада със следната HTTP заявка:"GET /content/geometrixx-outdoors/en/women.html"Не съответства на следната HTTP заявка:"GET /content/geometrixx-outdoors/en/men. html" *[o/]men.html* Съвпада със следните HTTP заявки: "GET /content/geometrixx-outdoors/en/women.html""GET /content/geometrixx-outdoors/en/men.html"-Означава набор от знаци. За използване в класове знаци. Извън клас знаци този знак се тълкува буквално.*[m-p]men.html* Съвпада със следната HTTP заявка: "GET /content/geometrixx-outdoors/en/women.html"Не съвпада следната HTTP заявка: "GET /content/geometrixx-outdoors/en/men.html"! Отрича символа или класа на знаци, който следва. Използвайте само за отричане на знаци и диапазони от знаци вътре в класове знаци. Еквивалентен на заместващия знак ^. Извън символен клас, този знак се интерпретира буквално.*[!o]men.html* Съвпада със следната HTTP заявка: "GET /content/geometrixx-outdoors/en/men.html"Не съответства на следната HTTP заявка: „GET /content/geometrixx-outdoors/en/women.html“*[!o!/]men.html* Не отговаря на следната HTTP заявка: „GET /content/geometrixx-outdoors/en/women.html“ или "GET /content/geometrixx-outdoors/en/men. html"^Отхвърля символа или диапазона от знаци, който следва. Използвайте само за отричане на знаци и диапазони от знаци в класове знаци. Еквивалентно на ! заместващ знак. Извън символен клас, този знак се интерпретира буквално. Примерите за ! се прилага заместващ знак, заместващ ! символи в примерните шаблони със знаци ^.В конфигурацията на уеб сървъра можете да зададете:
Местоположението на регистрационния файл на Dispatcher. Нивото на регистрационния файл.За повече информация се обърнете към документацията на уеб сървъра и readme файла на вашето копие на Dispatcher.
Apache Rotated / Piped Logs
Ако използвате уеб сървър на Apache, можете да използвате стандартната функционалност за ротирани и/или конвейерни журнали. Например, като се използват тръбопроводни трупи:
DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"
Това автоматично ще се завърти:
регистрационният файл на диспечера; с клеймо за време в разширението (logs/dispatcher.log%Y%m%d).на седмична база (60 x 60 x 24 x 7 = 604800 секунди).Моля, вижте документацията на уеб сървъра на Apache за ротация на регистрационни файлове и тръбни трупи; например Apache 2.4.
ЗАБЕЛЕЖКА
При инсталиране нивото на регистрационния файл по подразбиране е високо (т.е. ниво 3 = отстраняване на грешки), така че диспечерът регистрира всички грешки и предупреждения. Това е много полезно в началните етапи.
Това обаче изисква допълнителни ресурси, така че когато Dispatcher работи безпроблемно според вашите изисквания, можете (трябва) да намалите нивото на регистрационния файл.
Сред другите подобрения за Dispatcher, версия 4.2.0 въвежда също регистриране на проследяване.
Това е по-високо ниво от регистрирането на грешки, което показва допълнителна информация в регистрационните файлове. Той добавя регистриране за:
Стойностите на препратените заглавки; Правилото, което се прилага за определено действие.Можете да активирате записването на проследяване, като зададете ниво на регистър на 4 във вашия уеб сървър.
По-долу е даден пример за регистрационни файлове с активирано проследяване:
[Чет, 3 март, 16:05:38 2016] [T] [17183] request.headers[Хост] = "localhost:8443"[Чет, 3 март 16:05:38 2016] [T] [17183] request.headers[ User-Agent] = "curl/7.43.0"[четвъртък, 3 март, 16:05:38, 2016] [T] [17183] request.headers[Accept] = "*/*"[четвъртък, 3 март, 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"[четвъртък, 3 март 16:05:38 2016] [T] [17183] request.headers[Чрез ] = "1.1 localhost:8443 (диспечер)"[четвъртък, 3 март, 16:05:38, 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"[четвъртък, 3 март 16: 05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "включено"[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded- SSL-Cipher] = "DHE-RSA-AES256-SHA"[четвъртък, 3 март, 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91 f4a4d51232a934ae"[ Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers [Server-Agent] = "Communique-Dispatcher"И регистрирано събитие, когато се поиска файл, който отговаря на правило за блокиране:
[Чет, март 03, 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' беше блокиран поради /0082За потвърждение основна операция и взаимодействие на уеб сървъра, диспечера и екземпляра на AEM можете да използвате следните стъпки:
Задайте нивото на журнал на 3.
Стартирайте уеб сървъра; това също стартира диспечера.
Стартирайте екземпляра на AEM.
Проверете регистрационните файлове и файловете за грешки за вашия уеб сървър и диспечера.
В зависимост от вашия уеб сървър трябва да видите съобщения като: [четвъртък, 30 май, 05:16:36 2002] [известие] Apache/2.0.50 (Unix) е конфигуриран и [пт, 19 януари 17:22:16 2001] [I] [19096] Диспечерът е инициализиран (компилация XXXX)Сърфирайте в уебсайта чрез уеб сървъра. Потвърдете, че съдържанието се показва според изискванията. Например при локална инсталация, където AEM работи на порт 4502, а уеб сървърът на 80 има достъп до конзолата за уебсайтове, като използва и двете:
https://localhost:4502/libs/wcm/core/content/siteadmin.htmlhttps://localhost:80/libs/wcm/core/content/siteadmin.htmlРезултатите трябва да са идентични. Потвърдете достъпа до други страници със същия механизъм.Проверете дали директорията на кеша се попълва.
Активирайте страница, за да проверите дали кешът се почиства правилно.
Ако всичко работи правилно, можете да намалите loglevel до 0.
При сложни настройки можете да използвате няколко диспечера. Например можете да използвате:
един диспечер, за да публикува уебсайт в Intraneta, втори диспечер, под различен адрес и с различни настройки за сигурност, за да публикува същото съдържание в интернет.В такъв случай се уверете, че всяка заявка преминава само през един диспечер. Диспечерът не обработва заявки, които идват от друг диспечер. Затова се уверете, че и двамата диспечери имат директен достъп до уебсайта на AEM.
Когато добавя заглавката X-Dispatcher-Info към заявка, Dispatcher отговаря дали целта е била кеширана, върната от кеширана или изобщо не може да се кешира. Заглавката на отговора X-Cache-Info съдържа тази информация в четима форма. Можете да използвате тези заглавки на отговора за отстраняване на грешки, включващи отговори, кеширани от диспечера.
Тази функционалност не е активирана по подразбиране, така че за да бъде включена заглавката на отговора X-Cache-Info, фермата трябва да съдържа следния запис:
/info "1"Например,
/farm{/mywebsite{# Включете заглавката на отговора на X-Cache-Info, ако X-Dispatcher-Info е в заглавката на заявката/информация "1"}}Освен това заглавката на X-Dispatcher-Info не се нуждае от стойност, но ако използвате curl за тестване, трябва да предоставите стойност, за да изпратите заглавката, като например:
curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.htmlПо-долу е даден списък, съдържащ заглавките на отговорите, които X-Dispatcher-Info ще върне:
cachedЦелевият файл се съдържа в кеша и диспечерът е определил, че е валиден за доставянето му.cachingЦелевият файл не се съдържа в кеша и диспечерът е определил, че е валидно да кешира изхода и да го достави.caching: stat файлът е по-скорошен. Целевият файл се съдържа в кеша, но е невалиден от по-скорошен stat файл. Диспечерът ще изтрие целевия файл, ще го създаде отново от изхода и ще го достави. не може да се кешира: няма корен на документа Конфигурацията на фермата не съдържа корен на документа (конфигурационен елемент cache.docroot). не може да се кешира: пътят на кеширания файл е твърде дълъг Целевият файл - конкатенацията на корена на документа и URL файла - надвишава най-дългото възможно име на файл в системата. не може да се кешира: пътят на временния файл е твърде дълъг. Шаблонът за име на временен файл надвишава най-дългото възможно име на файл в системата. Диспечерът първо създава временен файл, преди действително да създаде или презапише кеширания файл. Името на временния файл е името на целевия файл с добавените към него знаци _YYYYXXXXXX, където Y и X ще бъдат заменени, за да се създаде уникално име. не може да се кешира: URL адресът на заявката няма разширение URL адресът на заявката няма разширение или има път след файловото разширение, например: /test.html/a/path.not cacheable: заявката не беше GET или HEAD HTTP методът не е нито GET, нито HEAD. Диспечерът приема, че изходът ще съдържа динамични данни, които не трябва да се кешират. не може да се кешира: заявката съдържа низ на заявка. Заявката съдържа низ на заявка. Диспечерът приема, че изходът зависи от дадения низ на заявката и следователно не се кешира.не може да се кешира: мениджърът на сесии не е удостоверил Кеша на фермата се управлява от мениджър на сесии (конфигурацията съдържа възел за управление на сесии) и заявката не съдържа подходящата информация за удостоверяване. не може да се кешира: заявката съдържа разрешение. На фермата не е разрешено да кешира изход ( allowAuthorized 0) и заявката съдържа информация за удостоверяване. не може да се кешира: целта е директория. Целевият файл е директория. Това може да сочи към някаква концептуална грешка, при която и URL, и някои подURL съдържат кеширани изходни данни, например ако заявка към /test.html/a/file.ext е на първо място и съдържа кеширани изходни данни, диспечерът няма да може за да кешира изхода на последваща заявка в /test.html.not cacheable: URL на заявката има завършваща наклонена черта URL на заявката има завършваща наклонена черта.not cacheable: URL на заявката не е в кеша правила Правилата за кеша на фермата изрично отказват кеширането на изхода на някои заявки URL.not cacheable: проверката на авторизацията отказа достъп. Проверката на авторизацията на фермата отказа достъп до кеширания файл.not cacheable: сесията не е валидна. Кешът на фермата се управлява от мениджър на сесии (конфигурацията съдържа възел за управление на сесии) и сесията на потребителя не е или вече не е валидна .not cacheable: отговорът съдържа no_cache. Отдалеченият сървър върна Dispatcher: no_cache заглавка, забранявайки на диспечера да кешира изхода.not cacheable: дължината на съдържанието на отговора е нула. Дължината на съдържанието на отговора е нула; диспечерът няма да създаде файл с нулева дължина.PREV: Поправка: Невъзможност за свързване с вашия DHCP сървър Грешка на Windows 7, 8 ...
NEXT: Коригиране на DHCP не е активиран за Wi-Fi в Windows - блог на Auslogics
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
