Określanie, w pliku JSON, reguł przekierowywania

Tokeny lokalizacji

Korzystając z tokenów lokalizacji, można ułatwić konstruowanie lokalizacji przekierowania. Można używać następujących tokenów lokalizacji:

• <$urlPath$>: część uzgadnianego adresu URL, stanowiąca ścieżkę.

• <$urlQueryString$>: cały napis-zapytanie zgodnego adresu URL.

• <$urlQueryStringExcept(nazwa1,nazwa2)$>: cały napis-zapytanie zgodnego adresu URL z wyjątkiem podanych parametrów.

• <$wildcard(N)$>: oparty na jedynce indeks zgodnego wieloznacznika w zgodnym adresie URL. (Analogiczne do \1..\9 w wyrażeniach regularnych.)

• <$nazwa$>: wartość nazwanego parametru napisu-zapytania. Na przykład, jeśli wejściowym napisem-zapytaniem jest msmith: ?page=42, można w lokalizacji użyć tokenu <$page$>, aby umieścić w niej liczbę 42.

Ograniczenia

Następujące ograniczenia obowiązują zarówno do całego pliku redirects.json, jak i zawartych w nim reguł:

• Maksymalny całego pliku, akceptowany przez Oracle Content Management, wynosi 250 KB.

• Maksymalna liczba reguł w pliku redirects.json wynosi 1000.

• Maksymalna długość właściwości "expression" reguły wynosi 1000 znaków.

• Maksymalna długość właściwości "location" reguły wynosi 2000 znaków.

• Maksymalna liczba tokenów * w wyrażeniu reguły wieloznacznej wynosi 10.

Przykład uzgadniania reguły "string"

Reguła:

        {
              "type": "string",
              "expression": "/old/page.jsp?id=material&type=glass",
              "location": "/new/<$id$>.htm"
        }            

Z regułą tą jest zgodny następujący adres URL:

/old/page.jsp?id=material&type=glass

• Lokalizacją docelową jest: /new/material.htm

• Zgodny jest cały URL, w tym napis-zapytanie.

• Mimo że we właściwości "location" został użyty token <$id$>, to nie jest on tu konieczny, ponieważ zgodny mógł być tylko jeden napis-zapytanie. Lokalizacja mogłaby zostać określona jako /new/material.htm.

Z regułą tą nie są zgodne następujące adresy URL:

• /old/page.jsp

  (W wyrażeniu reguły jest określony napis-zapytanie, który musi być zgodny.)

• /old/page.jsp?id=material&type=glass&index=2

  (Dodatkowy fragment &index=2 w kandydującym adresie URL powoduje, że adres ten nie jest w pełni zgodny z regułą.)

• /old/page.jsp?type=glass&id=material

  (Kolejność parametrów napisu-zapytania musi być identyczna z określoną w regule "string".)

Przykład uzgadniania reguły "wildcard"

Reguła:

        {
              "type": "wildcard",
              "expression": "/old/*/pages/*?id=*&item=sheet-*",
              "location": "/new/<$id$>/<$wildcard(4)$>.html"
        }            

Z regułą tą są zgodne następujące adresy URL:

• /old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs

  • Lokalizacją docelową jest: /new/XT1045/specs.html

  • Zgodna jest część adresu URL stanowiąca ścieżkę, a zatem także i napis-zapytanie jest sprawdzany pod kątem spełnienia warunków.

  • W tym przykładzie kolejność parametrów jest zgodna z ich kolejnością w wyrażeniu reguły, lecz nie jest to wymagane.

• /old/phones/android/pages/info.asp?item=sheet-specs&id=XT1045

  • Lokalizacją docelową jest: /new/XT1045/specs.html

  • Część adresu URL stanowiąca ścieżkę jest zgodna z wyrażeniem reguły przed znakiem zapytania (?), a zatem także i parametry są sprawdzane pod kątem zgodności.

  • Mimo że parametry są w wyrażeniu reguły podane w innej kolejności, to jednak są one uzgadniane indywidualnie.

• /old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs&unrelated=thing

  • Lokalizacją docelową jest: /new/XT1045/specs.html

  • Zgodna jest część adresu URL stanowiąca ścieżkę, a zatem także i napis-zapytanie jest sprawdzany pod kątem spełnienia warunków.

  • Kandydujący URL zawiera dodatkowy parametr &unrelated=thing, lecz — ponieważ są zgodne nazwane parametry zapytania występujące w wyrażeniu reguły — reguła jest uważana za zgodną.

  • Parametr unrelated mógłby być dostępny we właściwości "loaction" jako token <$unrelated$> i mógłby mieć wartość thing, mimo że nie ma to wpływu na uzgodnienie reguły.

Następujące adresy URL nie byłyby zgodne:

• /old/pages/info.jsp

  (Część adresu URL stanowiąca ścieżkę nie jest zgodna z częścią stanowiącą ścieżkę w wyrażeniu reguły.)

• /old/phones/android/pages/info.asp

  (Część adresu URL stanowiąca ścieżkę jest zgodna z częścią stanowiącą ścieżkę w wyrażeniu reguły, lecz nie są zgodne parametry zapytania występujące w wyrażeniu reguły.)

• /old/phones/android/pages/info.asp?id=cellular

  (Część adresu URL stanowiąca ścieżkę jest zgodna z częścią stanowiącą ścieżkę w wyrażeniu reguły, lecz nie wszystkie parametry zapytania występujące w wyrażeniu reguły są zgodne.)

Definiowanie tablicy tokenów

Można także utworzyć w pliku redirects.json tablicę definicji tokenów, pomagającą konfigurować przekierowania obsługujące wiele zindywidualizowanych adresów URL. Dzięki temu można dokonywać przekierowań na podstawie charakterystyki przychodzącego adresu URL.

Do zdefiniowania tokenów, przeznaczonych do użycia w adresach URL w regułach przekierowania, należy użyć w pliku redirects.json następującego formatu:

{
         "tokenDefinitions":
         [
                {
                        "token": "sitePrefix",
                        "type": "hostmatch",
                        "expresion": "example.com"
                        "value": ""
                },
                {
                        "token": "sitePrefix",
                        "type": "hostmatch",
                        "expresion": "*.com"
                        "value": "/site/Starter-Site"
                },
                {
                        "token": "gotoRedirect",
                        "type": "pathmatch",
                        "expresion": "*oracle*"
                        "value": "https://www.oracle.com"
                        "flags": "caseinsensitive"
                },              
        ]
}

Definicje tokenDefinitions mają następujące właściwości:

• "token": Nazwa definiowanego tokenu.

• "type": Jeden z następujących typów:

  • "hostmatch" — jest uzgadniana wartość hosta z przychodzącego adresu URL.

  • "pathmatch" — jest uzgadniana ścieżka z przychodzącego adresu URL.

  • "querymatch" — jest uzgadniana wartość zapytania z przychodzącego adresu URL.

• "expression": Wyrażenie używane do uzgadniania. Można stosować wieloznaczniki.

• "value": Wartość używana dla tokenu.

• "flags": Domyślnie w wyrażeniu uzgadniania jest uwzględniana wielkość liter, chyba że wartość flags zostanie ustawiona na caseinsensitive

Podczas obliczania wartości tokenu wpisy z tablicy tokenDefinitions są wyliczane w kolejności ich występowania. Jest używana pierwsza zgodna definicja. Jeśli dla tokenu nie zostanie uzgodniona żadna definicja, będzie użyty napis pusty. Ze względów praktycznych oraz wydajnościowych najczęściej używane tokeny powinny być umieszczane na początku listy tokenDefinitions list.

Lista tokenDefinitions ma następujące ograniczenia:

• Można utworzyć maksymalnie 250 definicji tokenów.

• Nazwa podana we właściwości token musi być krótsza niż 100 znaków.

• Wyrażenie podane we właściwości expression może zawierać maksymalnie 10 wieloznaczników.

• Wyrażenie podane we właściwości expression musi być krótsze niż 1000 znaków.

• Wartość podana we właściwości value musi być krótsza niż 1000 znaków.

Przykład

Na przykład można mieć następujący plik redirects.json:

{
         "redirectRules":
         [
                {
                        "type": "string",
                        "expression": "/legacy-privacy-policy.html",
                        "location": "<$pathPrefix$>/about/new-privacy-policy.html"
                },              
        ]
         "tokenDefinitions":
         [
                {
                        "token": "pathPrefix",
                        "type": "hostmatch",
                        "expression": "vanity.com"
                        "value": "/fashion"
                },                                              
        ]
}

W tym przypadku użyta w regule właściwość location zawiera token <$pathPrefix$>. Token pathPrefix jest zdefiniowany w sekcji tokenDefinitions. Jeśli przychodzący adres URL będzie zawierać "vanity.com", to wartość tokenu pathPrefix zostanie ustawiona na /fashion. Zostanie ona użyta w odpowiedzi location, dając w wyniku /fashion/about/new-privacy-policy.html.

Załóżmy, że pierwszym zindywidualizowanym adresem URL domeny jest http://example.com/legacy-privacy-policy.html. Zostanie wówczas uzgodniona pierwsza i jedyna reguła przekierowania.

Zadeklarowana lokalizacja location dla tej reguły to <$pathPrefix$>/about/new-privacy-policy.html. W tej sytuacji token <$pathPrefix$> musi zostać ustalony. W tym celu, aby odnaleźć zgodny wpis, jest przeglądana tablica tokenDefinitions.

Uwzględniana jest pierwsza definicja tokenu. Jej token jest właściwy i dlatego jest on dalej przetwarzany. Wyrażenie vanity.com nie jest zgodne z przychodzącym adresem URL example.com, a zatem ta definicja nie spełnia wymagań i jest kontynuowane wyliczanie.

Ponieważ nie ma dalszych definicji tokenów, jako wartość tokenu <$pathPrefix$> jest używany napis pusty. Ostateczną lokalizacją, zwracaną dla tego przekierowania, jest /about/new-privacy-policy.html.

Załóżmy, że drugim zindywidualizowanym adresem URL domeny jest http://vanity.com/legacy-privacy-policy.html. Podobnie jak w przypadku pierwszego adresu URL, zadeklarowana lokalizacja location dla tej reguły to <$pathPrefix$>/about/new-privacy-policy.html. W tej sytuacji token <$pathPrefix$> musi zostać ustalony. W tym celu, aby odnaleźć zgodny wpis, jest przeglądana tablica tokenDefinitions.

Uwzględniana jest pierwsza definicja tokenu. Jak poprzednio, jej token jest właściwy i dlatego jest on dalej przetwarzany. Wyrażenie vanity.com jest zgodne z przychodzącym adresem URL vanity.com, a zatem ta definicja spełnia wymagania i jako wartość tokenu jest używana wartość /fashion.

Ponieważ został znaleziony zgodny wpis dla tokenu, następuje zatrzymanie wyliczania tablicy definicji tokenów i ostateczna lokalizacja jest obliczana jako /fashion/about/new-privacy-policy.html.

Testowanie przekierowań do serwisu

Przekierowania do serwisu można przetestować, edytując serwis; w tym celu należy otworzyć panel Ustawienia, po czym kliknąć na ikonie Przekierowania. Wprowadzić testowany URL, po czym nacisnąć przycisk Test.