Dispatcher虛名URL
概觀
本檔案可協助您瞭解AEM如何處理虛名URL，以及使用重寫規則將內容對應到更接近傳送邊緣的其他技術
什麼是虛名URL
當您的內容位於合理的資料夾結構中時，它並不總是位於易於參照的URL中。 虛名URL就像捷徑。 參照實際內容所在位置的較短或唯一URL。
範例： /aboutus指向/content/we-retail/us/en/about-us.html
AEM作者可選擇在AEM中為內容設定虛名URL屬性並將其發佈。
若要使用此功能，您必須調整Dispatcher篩選器，以允許虛名通過。 以作者設定這些虛名頁面專案的速率調整Dispatcher設定檔案，會使這種狀況變得不合理。
因此，Dispatcher模組具備的功能可自動允許內容樹中列出的任何虛名。
運作方式
製作虛名URL
作者在AEM中造訪頁面、按一下頁面屬性，並在 虛名URL 區段中新增專案。 儲存變更並啟動頁面後，會將虛名指派給頁面。
作者也可以在新增 虛名URL 專案時，選取 重新導向虛名URL 核取方塊，這會使虛名URL行為類似於302重新導向。 這表示瀏覽器被告知要移至新URL （透過Location回應標頭），且瀏覽器會向新URL提出新要求。
觸控式UI：
傳統內容尋找器：
資源解析/對應
每個虛名專案都是用於內部重新導向的sling對應專案。
造訪AEM執行個體Felix主控台( /system/console/jcrresolver )即可看到對應
以下是虛專案建立的地圖專案的熒幕擷圖：
在上述範例中，當我們要求AEM執行個體造訪/aboutus時，它解析為/content/we-retail/us/en/about-us.html
Dispatcher自動允許篩選器
處於安全狀態的Dispatcher會透過Dispatcher篩選出路徑/上的請求，因為這是JCR樹的根目錄。
請務必確定發佈者僅允許來自/content和其他安全路徑等路徑的內容，而不允許/system等路徑。
以下是/的基本資料夾中的問題和虛名URL，那麼我們如何允許他們在保持安全的同時聯絡發佈者？
簡單Dispatcher具有自動篩選允許機制，您必須安裝AEM套件，然後設定Dispatcher指向該套件頁面。
Dispatcher的伺服器陣列檔案中有設定區段：
/vanity_urls {
/url "/libs/granite/dispatcher/content/vanityUrls.html"
/file "/tmp/vanity_urls"
/delay 300
}
以秒為單位測量的/delay引數不是以固定間隔為基礎運作，而是以條件為基礎的檢查。 在收到未列出URL的請求時，Dispatcher會評估/file （儲存已辨識的虛名URL清單）的修改時間戳記。 如果目前時刻與/file上次修改之間的時間差小於/delay期間，則不會重新整理/file。 重新整理/file會在兩個條件下發生：
- 傳入要求針對未快取或列於
/file中的URL。 - 自上次更新
/file以來，已經過了至少/delay秒。
此機制專門針對阻斷服務(DoS)攻擊而設計，這類攻擊可能會利用虛名URL功能讓Dispatcher不堪重負。
簡而言之，只有當要求到達不在/file中的URL時，以及/file的上次修改早於/delay句點時，才會更新包含虛名URL的/file。
若要明確觸發/file的重新整理，您可以在確認自上次更新以來經過必要的/delay時間之後，要求不存在的URL。 此用途的範例URL包括：
https://dispatcher-host-name.com/this-vanity-url-does-not-existhttps://dispatcher-host-name.com/please-hand-me-that-planet-maestrohttps://dispatcher-host-name.com/random-vanity-url
此方法會強制Dispatcher更新/file，前提是指定的/delay間隔自其上次修改後已過。
它將回應的快取儲存在/file引數中，所以在此範例中/tmp/vanity_urls
因此，如果您透過URI造訪AEM執行個體，便可看到其擷取內容：
從/libs/granite/dispatcher/content/vanityUrls.html
其實就是一份清單，非常簡單
將規則重寫為虛規則
為什麼要提到使用重寫規則，而不使用如上所述內建在AEM中的預設機制？
簡單來說，名稱空間問題、效能，以及可以更好處理的更高層級邏輯。
讓我們再看一下虛專案/aboutus的範例，看看其內容/content/we-retail/us/en/about-us.html （使用Apache的mod_rewrite模組來達成此目的）。
RewriteRule ^/aboutus /content/we-retail/us/en/about-us.html [PT,L,NC]
此規則會尋找虛名/aboutus，並從具有PT旗標(Pass Through)的轉譯器中擷取完整路徑。
它也會停止處理所有其他規則L標幟（最後），這表示它不必周遊大型規則清單，例如JCR解析必須執行的規則。
同時不必代理要求，並等待AEM發佈者回應此方法的這兩個元素，使其效能大幅提升。
此處錦上添花的是NC標幟（不區分大小寫），代表如果客戶以/AboutUs而不是/aboutus輸入URI，仍然有效。
若要建立重寫規則以執行此操作，您會在Dispatcher上建立設定檔（範例： /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules），並將其包含在.vhost檔案中，該檔案會處理需要套用這些虛名URL的網域。
以下是/etc/httpd/conf.d/enabled_vhosts/we-retail.vhost中包含的範常式式碼片段
<VirtualHost *:80>
ServerName weretail.com
ServerAlias www.weretail.com
........ SNIP ........
<IfModule mod_rewrite.c>
ReWriteEngine on
LogLevel warn rewrite:info
Include /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules
</IfModule>
........ SNIP ........
</VirtualHost>
哪一種方法及何處
使用AEM控制虛名專案具有以下優點
- 作者可以即時建立這些檔案
- 它們會與內容共存，並可與內容一起封裝
使用mod_rewrite控制虛名專案具有以下優點
- 解析內容的速度更快
- 更接近使用者內容請求的邊緣
- 更多擴充性和選項，可控制如何將內容對應到其他條件
- 可不區分大小寫
請同時使用這兩種方法，以下是建議與准則，以瞭解何時應使用哪一種方法：
- 如果虛值是暫時的，並且規劃了低層流量，則使用AEM內建功能
- 如果虛值是不經常變更且頻繁使用的裝訂端點，則使用
mod_rewrite規則。 - 如果虛名名稱空間（例如：
/aboutus）必須對同一AEM執行個體上的多個品牌重複使用，則使用重寫規則。
/brand1/aboutus、brand2/aboutus、brand3/aboutus的虛名URL。