Edge for Private Cloud 4.53.01 sürümündeki değişiklikler

Değişikliklere genel bakış

Edge for Private Cloud 4.53.01, platformun güvenlik durumunu iyileştiren ve gerekli yazılım ile kitaplıkların güncellenmiş sürümlerini içeren çeşitli değişiklikler sunar. Bu değişiklikler aşağıdaki politika türlerini etkiler:

Bu yükseltme nedeniyle kesintiye yol açabilecek, kümenizdeki proxy'lerde, paylaşılan akışlarda veya diğer yapılarda yapılan değişiklikleri belirlemek için değişiklik algılama aracını da kullanabilirsiniz.

Değişikliklerin ayrıntılı açıklaması

Bu bölümde, 4.53.01 sürümünde kullanıma sunulan ve yükseltme sırasında veya sonrasında iş akışlarınızı kesintiye uğratabilecek değişiklikler açıklanmaktadır. Potansiyel sorun alanlarını belirleme yöntemleri ve azaltma ya da geçici çözüm metodolojileri de ele alınır.

OAS (OpenAPI Specification) doğrulama politikası

Bağlam

OAS doğrulama politikası, gelen istekleri veya yanıtları OpenAPI 3.0 spesifikasyonunda (JSON veya YAML) tanımlanan kurallara göre doğrular. Edge for Private Cloud 4.53.01, OAS (OpenAPI spesifikasyonu) politikasında geliştirmeler sunar. Bu geliştirmeler, API yanıt gövdelerinin daha katı ve doğru şekilde doğrulanmasına odaklanır.

Değişiklikler

Edge for Private Cloud 4.53.01, OAS politikasının API yanıtlarını doğrulama şekliyle ilgili iki önemli değişiklik yaparak OpenAPI spesifikasyonunuzla daha uyumlu olmasını sağlar:

  • Senaryo 1:
    • Önceki davranış: OpenAPI spesifikasyonunuzda yanıt metni zorunlu olmasına rağmen hedef veya yukarı akış politikasından gelen gerçek yanıtta yanıt metni yoksa politika bunu doğrulama hatası olarak işaretlemiyordu.
    • Mevcut davranış: Politika artık bu senaryoda doğru şekilde bir doğrulama hatası (örnek: defines a response schema but no response body found) döndürerek beklenen ve gerçek yanıt arasında bir uyuşmazlık olduğunu belirtiyor.
  • Senaryo 2:
    • Önceki davranış: OpenAPI spesifikasyonunuzda açıkça yanıt metni beklenmediği belirtilmesine rağmen hedef veya yukarı akış politikasından gelen gerçek yanıtta bir metin varsa politika başarısızlıkla sonuçlanmazdı.
    • Mevcut davranış: Politika artık bu senaryoda hataya (ör. No response body is expected but one was found) neden olacak ve yanıtların belirtilen şemaya sıkı sıkıya bağlı kalmasını sağlayacak.

Çözüm

Değişiklik algılama aracını kullanarak veya manuel inceleme yoluyla yükseltmeden etkilenebilecek tüm proxy'leri ya da paylaşılan akışları belirleyin. Aşağıdaki koşullardan birinin geçerli olduğu tüm proxy'leri arayın:

  • OAS doğrulama politikası, Source etiketi response olarak ayarlanmış şekilde yapılandırılır.
  • OAS doğrulama politikası, yanıt oluşturan diğer politikaların yanıtını doğrular.

Aracı kullanıyorsanız aşağıdaki biçimde çıkış oluşturulur:

Kurumsal Ortam Yapı Adı Yapı Türü Düzeltme Politika Adı Politika Türü Etki Türü Etkilenen Alan Etki Kesinliği Belgeler
org2 geliştirme proxy2 proxy 4 oas-validateresponse OASValidation oas_content_type_handling Source=calloutresponse Orta zorlukta OAS Doğrulama Politikası
org1 üretim proxy3 sharedflow 1 oas-spec-validation OASValidation oas_content_type_handling Kaynak=yanıt Orta zorlukta OAS Doğrulama Politikası

Çıkış tablosundaki sütunların ayrıntılı açıklaması için Aracın çıkışını anlama bölümüne bakın.

Bir proxy veya paylaşılan akış tanımlandıktan sonra, yanıt gövdesinin varlığı ya da yokluğu konusunda yanıt ile OAS spesifikasyonunuzun uyumlu olduğundan emin olun. Trafik kalıplarınızı incelemek için standart Apigee izlemeyi kullanabilirsiniz. Hedef aralıklı olarak yanıt döndürüyorsa yanıtı OAS doğrulama politikasına iletmeden önce doğrulamak için diğer politikaları kullanın.

  • OAS spesifikasyon dosyanız bir yanıt gövdesi tanımlıyorsa hedef veya yukarı akış politikasından gelen yanıtta her zaman bir yanıt gövdesi sağlanmalıdır.
  • OAS spesifikasyon dosyanızda bir yanıt gövdesi tanımlanmıyorsa hedef veya yukarı akış politikası bir yanıt gövdesi göndermemelidir.

Private Cloud 4.53.01'e yükseltmeyi denemeden önce OAS doğrulama politikasını veya hedef davranışınızı gerektiği gibi güncelleyin. Üretim kümesi yükseltmesi sırasında kesinti riskini en aza indirmek için bu tür tanımlanmış iş akışlarını önce üretim dışı ortamlarınızda doğrulamanız gerekir.

JSON dosyasının yolu

Bağlam

Edge for Private Cloud 4.53.01, JSON yolu ifadelerinin çeşitli politikalarda kullanılma şeklini değiştirdi. JSONPath ifadeleri, JSON içeriğini ayrıştırmak veya değerleri değişkenlerde depolamak için ExtractVariable politikası, RegularExpressionProtection politikası, Veri maskeleme gibi politikalarda kullanılabilir. JSONPath ifadeleri, değişkenleri proxy yürütme sırasında değerlerle dinamik olarak değiştirmek için genel mesaj şablonlarında da kullanılabilir. Yeni JSONPath ifadeleri ve biçimleri, en son JSON ifade standartlarına uygundur.

Değişiklikler

JSONPath ifadelerini kullanan politikalar için mevcut API proxy'lerini/paylaşılan akışları incelemek önemlidir. Bu durum, Değişkenleri Çıkarma politikası, Normal İfade Koruması politikası veya JSONPath kullanan Mesaj Şablonu'na sahip tüm politikaları kapsar ancak bunlarla sınırlı değildir.

Aşağıdaki JSON girişi, değişiklikleri açıklamak için kullanılır:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. Nesne değerleri için JSONPath joker karakteri [*] davranış değişikliği

    Bir JSON nesnesinin tüm anlık değerlerine erişmek için kullanıldığında [*] joker karakterinin davranışı değiştirildi. Daha önce $.object[*], tek bir JSON nesnesine yerleştirilmiş anlık değerleri döndürüyordu. Güncellenen kitaplıklarla birlikte çıkış artık bu değerleri içeren bir dizi oluyor.

    Örneğin, $.store[*]:

    Önceki davranış:
    {
      "bicycle": {
        "color": "red",
        "book": [{"author": "Abc"}]
      },
      "book": [
        {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
        {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
        {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
      ]
    }
    
    Şu anki davranış:
    [
      [
        {"category": "reference", "author": "Nigel Rees", "price": 8.95},
        {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
        {"category": "fiction", "author": "Herman Melville", "price": 8.99}
      ],
      {
        "color": "red",
        "book": [{"author": "Abc"}]
      }
    ]
    
    İşlem:

    Daha önce alınan öğeleri doğrudan hedeflemek için JSONPath ifadesini yalnızca üst nesneyi hedefleyecek şekilde değiştirin (örnek: $.store).

  2. Yollardaki (.) JSONPath sondaki nokta hataya neden oluyor

    JSONPath ifadeleri için daha katı bir doğrulama vardır. Daha önce, geçersiz bir sondaki nokta (örnek: $.path.to.element.) ile biten yollar sessizce yoksayılıyordu ve önceki geçerli yol segmenti eşleştiyse sorgu yine de bir sonuç döndürüyordu. Yeni sürümde, bu tür hatalı biçimlendirilmiş yollar artık geçersiz olarak doğru şekilde tanımlanıyor ve hataya neden oluyor.

    Örneğin, $.store.book.

    Önceki davranış:
    [
      {"price":8.95,"category":"reference","author":"Nigel Rees"},
      {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
      {"price":8.99,"category":"fiction","author":"Herman Melville"}
    ]
    
    Şu anki davranış:
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
    

    JSONPath ifadelerini istenmeden eklenen bir nokta ile kullanan mevcut politikalar artık InvalidPathException ile başarısız olacak.

    İşlem:

    Nokta ile biten tüm JSONPath ifadelerindeki sondaki noktayı kaldırın. Örneğin, $.store.book. değerini $.store.book olarak değiştirin.

  3. JSONPath yinelemeli alt öğe (..) çıkış yapısı değişikliği

    Adlandırılmış bir öğenin tüm oluşumlarını bulmak için (..) (özyinelemeli iniş) operatörü kullanılırken sonuçların döndürülme şeklinde değişiklikler yapıldı. Daha önce, bulunan tüm öğeler tek bir listede birleştiriliyordu. Güncellenen kitaplıklar artık tek bir düz liste yerine, öğelerin bulunduğu orijinal gruplandırma yapısını koruyarak liste listesi döndürüyor.

    Örneğin, $..book

    Önceki davranış:
    [
      {"price":8.95,"category":"reference","author":"Nigel Rees"},
      {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
      {"price":8.99,"category":"fiction","author":"Herman Melville"},
      {"author":"Abc"}
    ]
    
    Şu anki davranış:
    [
      [
        {"category":"reference","author":"Nigel Rees","price":8.95},
        {"category":"fiction","author":"Evelyn Waugh","price":12.99},
        {"category":"fiction","author":"Herman Melville","price":8.99}
      ],
      [
        {"author":"Abc"}
      ]
    ]
    
    İşlem:

    Aşağı akış işleme mantığınızı, yeni iç içe dizi yapısını hesaba katacak şekilde güncelleyin. Tek tek öğelere erişmek için büyük olasılıkla dıştaki JSONArray'da ve ardından her bir içteki JSONArray'da yineleme yapmanız gerekir.

  4. Çoklu öğe seçimi veya filtrelemeden sonra JSONPath dizine ekleme işlemi boş dizi döndürüyor

    Bir dizin (örnek: [0]) çok öğeli seçiciden ([*] gibi) veya filtreden ([?(condition)]) hemen sonra uygulandığında davranışta değişiklik olur. Daha önce bu tür ifadeler, belirtilen dizindeki öğeyi birleştirilmiş sonuçlardan seçmeye çalışırdı. Yeni sürümde bu ifadeler artık boş bir dizi ([]) döndürecek.

    Örneğin, $.store.book[*][0]

    Önceki davranış:
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    
    Şu anki davranış:
    []
    
    İşlem:

    Filtreleme yapıldıktan sonra filtrelenen kümeden belirli bir öğenin alınması gerekiyorsa örneğin, JSONPath tarafından döndürülen filtrelenmiş diziyi $..book[?(@.category == 'fiction')] işleyin ve ardından önceki sonuçtan [0] öğesini alın.

  5. JSONPath negatif dizi dilimleme çıkış değişikliği

    Yeni sürümde negatif dizi dilimleme davranışı değiştirildi (örnek: [-2:], [-1:]). Daha önce, bir diziye negatif dilimleme uygulandığında (dizinin sonundaki öğeleri belirtme), eski sürüm bu dilimden yalnızca tek bir öğeyi yanlış şekilde döndürüyordu. Yeni sürüm artık belirtilen negatif aralığa giren tüm öğeleri içeren bir liste (dizi) döndürüyor.

    Örneğin $.store.book[-2:]

    Önceki davranış:
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    
    Şu anki davranış:
    [
      {"category":"fiction","author":"Evelyn Waugh","price":12.99},
      {"category":"fiction","author":"Herman Melville","price":8.99}
    ]
    
    İşlem:

    Artık istenen çıktıyı almak için döndürülen JSON dizisinde yineleme yapacak şekilde sonraki işleme mantığının güncellenmesi gerekiyor.

  6. JSONPath'te daha katı ön nokta

    Doğrudan kökten erişilen öğeler için söz dizimi daha katı bir şekilde uygulanır. Öğelere, kökten doğrudan erişildiğinde (örnek: $propertyelement) bu söz dizimi artık hata olarak kabul ediliyor ve proxy dağıtımını engelliyor.

    Örneğin $store,

    {
      "bicycle": {
        "color": "red",
        "book": [{"author": "Abc"}]
      },
      "book": [
        {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
        {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
        {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
      ]
    }
    

    Şu anki davranış:

    Proxy will fail to deploy.

    İşlem:

    JSONPath'inizi noktayı içerecek şekilde değiştirin: $.propertyName (örnek: $.store). Bu, değeri doğru şekilde hedefler ve alır.

  7. Dinamik JSONPath ifadeleri

    JSONPath ifadesinin kendisinin bir değişken tarafından sağlandığı politikalara (örnek: {myJsonPathVariable} veya {dynamicPath}) dikkat edin. Bu değişkenlerin değeri de yukarıda belirtilen olası davranış değişikliklerine göre kontrol edilmelidir.

Çözüm

Değişiklik algılama aracını kullanarak veya API proxy'lerinizi manuel olarak inceleyerek yükseltmeden etkilenebilecek tüm proxy'leri veya paylaşılan akışları belirleyin. Aracı kullanırsanız çıkışta, etkilenen proxy veya paylaşılan akış, ilgili politika ve sorunlu JSON yolları aşağıdaki örnek çıkışta gösterildiği gibi tanımlanır:

Kurumsal Ortam Yapı Adı Yapı Türü Düzeltme Politika Adı Politika Türü Etki Türü Etkilenen Alan Etki Kesinliği Belgeler
org1 geliştirme proxy1 proxy 4 EV-ExtractRequestParams ExtractVariables Nesne Değerleri İçin JSONPath Joker Karakter [*] Davranış Değişikliği $.store[*] Yüksek Nesne Değerleri İçin JSONPath Joker Karakter [*] Davranış Değişikliği
org2 üretim proxy2 sharedflow 1 EV-ExtractResponseParams ExtractVariables JSONPath'teki yollarda bulunan sondaki nokta (.) artık hataya neden oluyor $.store.book. Yüksek Yollarda JSONPath'in sonuna nokta (.) eklenmesi hataya neden oluyor
org3 geliştirme proxy3 proxy 3 SC-FetchUserProfile ServiceCallout JSONPath Recursive Descent (..) Çıkış Yapısı Değişikliği $..book Yüksek JSONPath yinelemeli alt öğe (..) çıkış yapısı değişikliği
org4 üretim proxy4 sharedflow 2 RF-InvalidAuthToken RaiseFault Çoklu öğe seçimi veya filtrelemeden sonra JSONPath dizin oluşturma artık boş dizi döndürüyor $.store.book[*][0] Yüksek Çoklu öğe seçimi veya filtrelemeden sonra JSONPath dizin oluşturma işlemi boş dizi döndürüyor
org5 test proxy5 proxy 6 SC-FetchProfileDetails ServiceCallout JSONPath Negatif Dizi Dilimleme Çıktısı Değişikliği $.store.book[-2:] Yüksek JSONPath negatif dizi dilimleme çıkış değişikliği
org6 üretim proxy6 proxy 2 ML-LogRequestDetails MessageLogging JSONPath Stricter Preceding Dot $store Yüksek JSONPath'te nokta öncesinde daha katı kurallar
org7 test proxy7 proxy 5 RF-InvalidTokenDetails RaiseFault Dinamik JSONPath İfadeleri myJsonPathVariable Orta zorlukta Dinamik JSONPath ifadeleri

Yukarıdaki çıktı tablosundaki sütunların ayrıntılı açıklaması için Aracın çıktısını anlama bölümüne bakın.

Bu durumu azaltmak için kapsamlı bir strateji gereklidir. Bu süreçte, uygun güncelleme yoluna karar verilir ve algılanan JSONPath ifadeleri için gerekli düzeltme uygulanır.

Size en uygun yükseltme yolu yöntemini seçin:

  • Sıfır Kapalı Kalma Süresiyle Taşıma

    Bu strateji, ayrı ileti işlemci düğümlerini bağlayabilmeniz için bir veya daha fazla yeni ortam tedarik etmeyi içerir. Bu tür ileti işlemci düğümleri, 4.53.01 sürümünü yükleyecek şekilde ayarlanabilir ve modern JSONPath ifadeleri içeren proxy'lere sahip olabilir. Bu cihazlar, yükseltme sırasında kullanılabilir ve yükseltme tamamlandıktan sonra devre dışı bırakılabilir. Bu strateji sorunsuz olsa da sorunsuz bir yükseltmeyi desteklemek için geçici olarak ek ileti işlemcisi düğümleri tedarik etmeyi içerir. Ayrıntılar aşağıda verilmiştir:

    • Yeni bir ortam oluşturun ve bu yeni ortama 4.53.01 sürümünün yeni mesaj işleme düğümlerini ekleyin.
    • Etkilenen proxy'lerin proxy paketini yeni ortama yükleyin, düzeltme bölümünde açıklanan gerekli düzeltmeleri uygulayın ve güncellenen proxy paketini yeni ortama dağıtın.
    • Trafiği yeni ortama yönlendirin ve etkilenen proxy'leri eski ortamdan kaldırın.
    • Orijinal ileti işlemci düğümlerini 4.53.01 sürümüne yükseltin. Orijinal ortamda JSONPath ile ilgili düzeltmeler içeren proxy'leri dağıtın.
    • Trafiği, artık 4.53.01 sürümünde mesaj işlemcileri ve yeni jsonpath ifadeleri için modernleştirilmiş bir proxy'ye sahip olan eski ortama geri yönlendirin.
    • Yeni ortamı ve ilişkili düğümleri silin ve hizmetten kaldırın.
  • Kapalı kalma süresi ve yükseltme

    Bu strateji, hatalı JSON yolu ifadeleri kullanarak API proxy'leri için kapalı kalma süresi elde etmeyi içerir. Ek mesaj işlemcisi düğümleri satın almayı gerektirmez ancak etkilenen proxy'ler için API trafiğinde kesintiye neden olur.

    • Etkilenen politikalarla etkilenen proxy'leri belirleyin ve etkilenen tüm proxy'ler için yeni bir düzeltme oluşturun.
    • Gerekli düzeltmeleri, düzeltme bölümünde açıklanan düzeltmeleri vekil sunucunun yeni bir revizyonunda uygulayarak yapın. Bunu henüz dağıtmayın.
    • Etkilenen proxy'ler için hizmet dışı kalma süresi ayarlayın.
    • Tüm ileti işlemcileri, özel bulut sürümü 4.53.01 için Edge'e yükseltin. Mevcut proxy'lerin, yeni yükseltilen ileti işlemcilerinde başarısız olabileceğini unutmayın.
    • Tüm ileti işlemciler Edge for private cloud sürüm 4.53.01'e yükseltildikten sonra , düzeltilmiş JSONPath ifadesiyle yeni oluşturulan proxy revizyonunu dağıtın.
    • Bu tür proxy'lerde trafiğe devam edin.
  • Yükseltmeden önce Proxy'yi yeniden tasarlama

    Edge for Private Cloud 4.53.01'e yükseltmeden önce proxy'yi yeniden tasarlayabilirsiniz. Belirli JSON yolu ifadelerini kullanmak yerine farklı bir yöntemle aynı sonucu elde edebilirsiniz.

    Örneğin, JSON yoluyla bir Değişken Ayıklama Politikası kullanıyorsanız daha yeni sürüme yükseltmeden önce politikayı benzer verileri ayıklayan bir JavaScript politikasıyla değiştirebilirsiniz. Yükseltme işlemi tamamlandıktan sonra, proxy'nizi daha yeni biçimlerle JSON yollarını kullanacak şekilde değiştirebilirsiniz.

JavaCallout değişiklikleri

Bağlam

Private Cloud için Edge 4.53.00 ve önceki sürümlerinde, bir dizi JAR kitaplığı içeren deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) adlı bir dizin bulunuyordu. Bu kitaplıklar, JavaCallout politikası'ndaki Java kodunda kullanılabilir ve özel Java kodunuz tarafından doğrudan veya dolaylı olarak kullanılmış olabilir.

Değişiklikler

Desteği sonlandırılan dizin, Private Cloud için Edge 4.53.01 sürümünde kaldırıldı. Java kodunuz bu tür kitaplıklara bağlıysa mesaj işlemciler 4.53.01 sürümüne yükseltildiğinde bu tür Java çağrılarını kullanan proxy'ler başarısız olur. Bu tür hataları önlemek için ileti işlemcileri 4.53.01 sürümüne yükseltmeden önce aşağıdaki azaltma adımlarını uygulayın.

Çözüm

  1. Değişiklik algılama aracını kullanarak veya manuel olarak Java Callout politikalarınızı ve ilişkili JAR'larınızı inceleyin. Politikalardan herhangi birinin, mevcut ileti işlemcilerinizin "kullanımdan kaldırılan" dizininde bulunan kitaplıklara referans verip vermediğini kontrol edin.

    Yukarıdaki algılamalar için Apigee tarafından sağlanan aracı kullanıyorsanız araç, aşağıdaki tabloda gösterildiği gibi bir rapor oluşturur . Daha ayrıntılı belirtmek gerekirse, bu politika eski Edge for Private Cloud sürümlerinin $APIGEE_ROOT/edge-message-processor/lib/deprecated dizininde bulunan JAR'lara referans veren politikaları hedefler.

    Araç, aşağıdaki biçimde raporlar oluşturur:

    Kurumsal Ortam Yapı Adı Yapı Türü Düzeltme Politika Adı Politika Türü Etki Türü Etkilenen Alan Etki Kesinliği Belgeler
    org1 Yok Yok org-level-jar Yok Yok java-callout simple-javacallout-o1-jar-1.jar için desteği sonlandırılan kitaplık algılandı ["commons-io-2.5.jar sınıfının org.apache.commons.io.FileUtils tarafından kullanıldığı tespit edildi", "commons-io-2.5.jar sınıfının commons-io-2.5.jar tarafından kullanıldığı tespit edildi"]org.apache.commons.io.input.XmlStreamReaderException Yüksek JavaCallout değişiklikleri
    org3 env3 Yok env-level-jar Yok Yok java-callout fat-javacallout-e3-jar-1.jar için desteği sonlandırılan kitaplık algılandı ["httpclient-4.5.2.jar sınıfının org.apache.http.impl.auth.NTLMSchemeFactory kullanımı algılandı"] Yüksek JavaCallout değişiklikleri
    org1 env1 p1 proxy-level-jar 1 Yok java-callout simple-javacallout-p1-jar-1.jar için desteği sonlandırılan kitaplık algılandı ["commons-lang3-3.4.jar kaynağından org.apache.commons.lang3.builder.ToStringBuilder sınıfının kullanımı algılandı", "commons-lang3-3.4.jar kaynağından org.apache.commons.lang3.Validate sınıfının kullanımı algılandı"] Yüksek JavaCallout değişiklikleri

    Yukarıdaki çıkış tablosundaki sütunların ayrıntılı açıklaması için Aracın çıkışını anlama bölümüne bakın.

  2. Bu tür kullanımdan kaldırılmış kitaplıkları belirledikten sonra sorunu azaltmak için aşağıdaki yöntemlerden birini uygulayabilirsiniz.
    • Kaynak yerleştirme (Java-Callout JAR'ları tarafından referans verilen, kullanımdan kaldırılmış dizinden az sayıda JAR / kitaplığınız varsa önerilir)
      • Belirlenen kullanımdan kaldırılmış JAR'ları, istenen düzeyde (API proxy düzeltmesi, ortam veya kuruluş) kaynak olarak yükleyin.
      • Apigee yazılımını her zamanki gibi yükseltmeye devam edin.
    • Manuel Yerleştirme (Java-Callout JAR'ları tarafından referans verilen çok sayıda JAR / kitaplığınız varsa önerilir)
      • Her ileti işlemci düğümünde, $APIGEE_ROOT/data/edge-message-processor/ yolunda external-lib adlı yeni bir dizin oluşturun.
      • Belirlenen JAR'ları, kullanımdan kaldırılan dizinden bu external-lib dizinine kopyalayın: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Dizin ve temel JAR'ların Apigee kullanıcısı tarafından okunabildiğinden emin olun: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Apigee yazılımını her zamanki gibi yükseltmeye devam edin.

OpenLDAP değişikliği

Bağlam

OpenLDAP, Edge Private Cloud'da hem kimlik doğrulama hem de yetkilendirme için kullanılabilir. Edge for Private Cloud 4.53.01'de, Apigee tarafından gönderilen OpenLDAP yazılımı 2.4 sürümünden 2.6 sürümüne yükseltildi.

Değişiklikler

OpenLDAP 2.6'da, göreceli ayırt edici ad (RDN) yaklaşık 241 bayt/karakterle sınırlıdır. Bu sınırlama, zorunlu kılınan bir üst sınırdır ve değiştirilemez.

Etki
  • Aşırı büyük RDN'lere sahip girişlerde replikasyon veya içe aktarma hataları oluşur.
  • Kuruluşlar,ortamlar, özel roller, izinler vb. gibi öğeler oluşturmaya çalıştığınızda "message": "[LDAP: error code 80 - Other]" hata mesajı gösterilebilir.
  • Apigee'nin LDAP'sinde 241 bayttan uzun olan tüm DN'ler etkilenir. Bu tür DN'ler, Apigee OpenLDAP yazılımının başarılı bir şekilde yükseltilmesini engeller. Yükseltme işlemine devam edebilmek için bu tür öğelerle ilgili azaltma stratejilerini uygulamanız gerekir.

Genel olarak, Apigee'nin LDAP'sinde uzun DN'ler, birden fazla öğe birleştirilerek oluşturuldukları için izinlerle ilgilidir. Bu tür izin girişleri özellikle yükseltme sorunlarına yatkındır.

Örneğin,

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

Genellikle, LDAP'deki RDN'lerin 241 bayttan küçük olması için kuruluş, ortam ve rol adlarınızın uzunluğu yeterli olur.

Çözüm

4.53.01 sürümüne yükseltmeden önce:

Aşağıdaki adımlar, mevcut LDAP 2.4 kümenizde uzun RDN'lerin varlığını doğrulamanıza yardımcı olur.

#1 - LDAP verilerini ayıklama

ldapsearch komutunu kullanarak ayırt edici adı (dn) bulun ve çıkışı bir dosyaya yönlendirin:

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Yukarıdaki DN.ldif dosyasında LDAP girişleri olduğundan emin olun.

#2 - Uzun RDN'leri belirleme

Değişiklik algılama aracı, 241 bayt/karakteri aşan LDAP RDN'lerini belirlemek için oluşturulan bir LDIF dosyasını kullanır.

Araç, raporları aşağıdaki biçimde oluşturur:

Kurumsal Ortam Yapı Adı Yapı Türü Düzeltme Politika Adı Politika Türü Etki Türü Etkilenen Alan Etki Kesinliği Belgeler
Yok Yok cn=really-long-name,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com ldif dosyası Yok Yok Yok Ldap RDN 241 karakteri aşıyor cn=really-long-name Yüksek OpenLDAP değişikliği

Yukarıdaki çıktı tablosundaki sütunların ayrıntılı açıklaması için Aracın çıktısını anlama bölümüne bakın.

Yukarıdaki komut herhangi bir çıkış üretmezse mevcut LDAP kurulumundaki hiçbir RDN 241 baytı/karakteri aşmıyor demektir. Yükseltme işlemine her zamanki gibi devam edebilirsiniz.

Yukarıdaki komut bir çıktı oluşturursa 241 baytı/karakteri aşan RDN'lerin varlığı belirtilir. Bu tür öğeler için Edge for Private Cloud 4.53.01 yükseltme işlemine devam etmeden önce 3. adımda açıklanan azaltma adımlarını uygulayın.

#3 - Uzun RDN'leri işleme

2. adımda çıktı alınırsa 241 baytı/karakteri aşan RDN'lerin varlığı söz konusudur. Bu durumda aşağıdaki azaltma adımlarını uygulayın:

241 baytı aşan LDAP girişlerini inceleyin.

  • RDN'nin uzun olmasına neden olan temel faktör özel rol adı, uygulama, API ürünü veya diğer öğelerse daha kısa bir ada sahip alternatif bir öğe kullanmaya geçin.
  • Uzun RDN'ye asıl katkıda bulunan kuruluş adı veya ortam adıysa daha kısa bir ada sahip farklı bir kuruluşa ya da ortama geçmeniz gerekir.

LDAP'nizdeki RDN'ler 241 bayttan kısa olana kadar yukarıdaki adımları tekrarlayın. Bu duruma ulaştıktan sonra özel bulut sürümünü her zamanki gibi yükseltmeye devam edin.

Kriptografi sağlayıcısı değişiklikleri

Bağlam

Bu değişiklik, Edge for Private Cloud 4.53.00 sürümünden aktarılmıştır. Edge for Private Cloud 4.53.00'da FIPS desteğini etkinleştirmek için dahili kriptografi sağlayıcı Bouncy Castle'dan (BC) Bouncy Castle FIPS'e (BCFIPS) güncellendi.

Değişiklikler

JavaCallout politikaları, özellikle BCFIPS sağlayıcısında güvenliği artırılmış güvenlik işlevleri (örneğin, hem şifreleme hem de imzalama için ortak bir anahtar çifti kullanma) kullanılırken orijinal BC sağlayıcısının kullanılmasını gerektiriyorsa bu tür JavaCallout politikalarının modernleştirilmesi gerekir. BC adını kullanarak Bouncy Castle kriptografi sağlayıcısını yüklemeye çalışan JavaCallout politikaları, varsayılan sağlayıcı değiştiği için başarısız olabilir. BC sağlayıcısını kullanan bu tür politikalar daha sonra bozulabilir. Eski BC sağlayıcısını kullanan özel uygulamalara artık erişilemeyecek. Bu uygulamaların incelenmesi ve yeniden uygulanması gerekecek.

Çözüm

Önerilen geçici çözüm, BCFIPS sağlayıcısını kullanmaktır. Eski sağlayıcıya dayanan özel JavaCallout uygulamalarının incelenmesi ve "BCFIPS" dizesi kullanılarak erişilebilen Bouncy Castle FIPS sağlayıcısı kullanılarak yeniden uygulanması gerekir.

Değişiklik algılama aracı

Edge for Private Cloud 4.53.01'e geçiş sırasında ve sonrasında etkilenebilecek Apigee proxy'lerini, politikalarını ve paylaşılan akışlarını belirlemek için bir değişiklik algılama aracı oluşturuldu. Bu araç, değişikliklerden etkilenen dağıtılmış proxy'ler, paylaşılan akışlar ve OpenLDAP'ı ayrıntılı olarak açıklayan bir rapor oluşturur ve tanımlanan proxy'ler veya paylaşılan akışlarla ilgili belirli kılavuzlara ve stratejilere yönlendirme sağlar.

Ön koşullar

  1. Bu aracı çalıştırmak için RHEL tabanlı bir makine gerekir.
  2. Aracın komut dosyalarının çalışmasına izin vermek için ana makine sanal makinesine JRE 8 yüklenmeli ve doğru şekilde yapılandırılmalıdır.
  3. Araç, kimlik doğrulama ve veri alma için Yönetim Sunucusu'nun doğru uç noktasını (URL) ve geçerli yönetici kimlik bilgilerini gerektirir.
  4. Araç, paketleri ayıklamak, günlük oluşturmak ve çıkışı depolamak için belirlenmiş bir çalışma dizinine (ör. /tmp) erişim gerektirir. Bu dizinde yeterli disk alanı ve uygun okuma/yazma izinleri olduğundan emin olun.
  5. Araç, 241 karakterden / bayttan uzun RDN'leri algılamak için OpenLDAP değişikliği - LDAP verilerini ayıklama bölümündeki ldapsearch komutunu kullanan LDIF dosyasını gerektirir.

Aracı çalıştırma

Yukarıda listelenen tüm ön koşullar karşılandıktan sonra, Apigee deposuna erişmek için kullandığınız Apigee kullanıcı adını ve şifresini sağlayarak aracı indirin. İndirilen arşivi ayıklayın.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip
unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

İndirme işlemi tamamlandıktan sonra araçla ilgili tüm seçenekleri görmek için aşağıdaki komutu çalıştırabilirsiniz:

./change-detector --help

Aracı çalıştırmak için aşağıdaki komutu kullanın ve yer tutucuları bilgilerinizle değiştirin:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Büyük RDN LDAP girişlerini algılamak için aşağıdaki komutu çalıştırın:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

Araç, doğrudan kullanılabilen veya Google E-Tablolar gibi okunabilir bir araca aktarılabilen json ya da csv biçiminde çıktı oluşturur.

Araç çıkışını anlama

Kurumsal

Yapının bulunduğu kuruluşun adını gösterir. OpenLDAP değişikliği için bu değer None olur.

Ortam

Kuruluş içindeki belirli ortam (ör. geliştirme, test, üretim). OpenLDAP değişikliği için bu değer None olur.

Java Callout değişikliklerinde, Artifact Type=env-level-jar ise bu alan None olur.

Yapı adı

Bu alan, proxy'nin/paylaşılan akışın adı hakkında bilgi verir. OpenLDAP değişikliği için bu alanda RDN'nin LDAP varlığı gösterilir.

Java Callout değişikliklerinde, Artifact Type=env-level-jar veya org-level-jar ise bu alan None olur.

Yapı türü

  • OAS ve JSON değişiklikleri için bu sütunda, yapay nesne, proxy veya paylaşılan akış türü belirtilir.
  • Java Callout değişikliği için bu sütunda, etkilenen jar'ın yüklendiği yer veya düzeyle ilgili ayrıntılar sağlanır. Kaynaklar (JAR'lar) üç düzeyden birinde depolanabilir: org-level, env-level, proxy-level.
  • OpenLDAP değişikliği için bu alan, araçta kullanılan LDIF dosyasını gösterir.

Düzeltme

Etkilenen proxy'nin/paylaşılan akışın dağıtılan düzeltmesini gösterir. OpenLDAP değişikliği için None olacaktır.

Politika adı

Olası sorun olarak tanımlanan belirli politikanın adı. OpenLDAP değişikliği için None olacaktır.

Politika türü

Politikanın türünü gösterir. OpenLDAP değişikliği için None olacaktır.

Etkinin türü

  • Bu alan, bir proxy/paylaşılan akışta algılanan belirli değişiklik türünü açıklar.
  • Java Callout değişikliği için, java-callout'larla ilgili değişikliklerin algılanması durumunda araç, bu sütunda şu şekilde Edge for Private Cloud'un eski sürümlerinin $APIGEE_ROOT/edge-message-processor/lib/deprecated dizininde bulunan JAR'lara referans veren etkilenen java-callout'u işaret eder.
  • deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR
  • OpenLDAP değişikliği için bu alan, herhangi bir LDAP öğesinin RDN'sinin 241 baytı veya karakteri aşıp aşmadığını gösterir.

Belirli bir alanı etkileme

  • OAS değişikliği için bu alan, politikanın Kaynak etiketinde kullanılan değişkenin adıdır.
  • JSON değişikliği için bu alanda, olası sorun olarak işaretlenen tam JSONPath ifadesi veya öğe gösterilir.
  • Java Callout değişikliği için bu alanda, etkilenen JavaCallout JAR'ı tarafından kullanılan/referans verilen tam sınıfların ayrıntıları ve karşılık gelen JAR'ın adı (eski Özel Bulut sürümlerinin $APIGEE_ROOT/edge-message-processor/lib/deprecated dizininde bulunur) yer alır. Bu, 4.53.01 sürümüne yükseltme sırasında, azaltılmadığı takdirde hatalara yol açar.
  •  ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
        Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
      .. , .. , ]
  • OpenLDAP değişikliği için bu alanda, 241 bayt veya karakteri aşan LDAP varlığının RDN'si gösterilir.

Etki kesinliği

  • Bu alan, aracın belirli bir öğeyi ne kadar kesinlikle algıladığı hakkında bilgi verir. Bu sütunun değerleri Yüksek veya Orta olabilir (daha sonra başka değerler eklenebilir).

    Yüksek değer, aracın, öğenin 4.53.01 sürümüne yükseltildikten sonra uygulamanın bozulmasına neden olma olasılığının çok yüksek olduğunu belirlediği anlamına gelir. Orta değeri, aracın algılama konusunda net olmadığını ve bir belirleme yapmak için daha fazla stratejiye ihtiyaç duyulduğunu gösterir (ör. proxy yürütme sırasında çözülen değişkenleri gözlemlemek için iz yakalama).

  • JavaCallout ve OpenLDAP değişiklikleriyle ilgili algılamalar, etki kesinliği sütunlarında her zaman Yüksek değerine sahip olur.

Belgeler

Bu sütunda, sorunu ve azaltma adımlarını açıklayan Apigee'nin dokümanlarına (bu makalenin ilgili bölümleri) yönlendiren bir köprü bulunur.