การเปลี่ยนแปลงใน Edge สำหรับ Private Cloud 4.53.01

ภาพรวมของการเปลี่ยนแปลง

Edge สำหรับ Private Cloud 4.53.01 ได้ทำการเปลี่ยนแปลงหลายอย่างเพื่อเพิ่มท่าทีด้านความปลอดภัยของแพลตฟอร์ม โดยรวมซอฟต์แวร์/ไลบรารีเวอร์ชันที่อัปเดตแล้ว การเปลี่ยนแปลงเหล่านี้ส่งผลต่อสิ่งต่อไปนี้

  • นโยบายการตรวจสอบ OAS (ข้อกำหนด OpenAPI)
  • นโยบายที่รองรับการค้นหา JSONPath
  • นโยบายการเรียกใช้ Java ที่ใช้ไลบรารีที่เลิกใช้งานแล้ว
  • OpenLDAP

ส่วนนี้จะอธิบายการเปลี่ยนแปลงประเภทต่างๆ ที่เปิดตัวในเวอร์ชัน 4.53.01 ซึ่งอาจขัดขวางเวิร์กโฟลว์ของคุณระหว่างหรือหลังการอัปเกรด นอกจากนี้ ยังครอบคลุมวิธีการระบุพื้นที่ที่อาจเกิดปัญหาและวิธีการลดหรือวิธีแก้ปัญหาชั่วคราวด้วย

นโยบายการตรวจสอบ OAS (ข้อกำหนด OpenAPI)

บริบท

นโยบายการตรวจสอบ OAS จะตรวจสอบคำขอหรือการตอบกลับขาเข้ากับกฎที่กำหนดไว้ในข้อกำหนด OpenAPI 3.0 (JSON หรือ YAML) Edge for Private Cloud 4.53.01 มีการปรับปรุงนโยบาย OAS (ข้อกำหนด OpenAPI) โดยมุ่งเน้นที่การตรวจสอบเนื้อหาการตอบกลับของ API ที่เข้มงวดและแม่นยำยิ่งขึ้น

การเปลี่ยนแปลง

Edge for Private Cloud 4.53.01 มีการเปลี่ยนแปลงที่สำคัญ 2 อย่างในวิธีที่นโยบาย OAS ตรวจสอบการตอบกลับของ API เพื่อให้สอดคล้องกับข้อกำหนด OpenAPI มากขึ้น ดังนี้

  • สถานการณ์ที่ 1:
    • ลักษณะการทำงานก่อนหน้า: หากข้อกำหนด OpenAPI ของคุณกำหนดให้ต้องมีเนื้อหาการตอบกลับ แต่การตอบกลับจริงจากนโยบายเป้าหมายหรือนโยบายต้นทางไม่มีเนื้อหาการตอบกลับ นโยบายจะไม่แจ้งว่านี่เป็นข้อผิดพลาดในการตรวจสอบ
    • ลักษณะการทำงานปัจจุบัน: ตอนนี้นโยบายจะแสดงข้อผิดพลาดในการตรวจสอบอย่างถูกต้อง (เช่น defines a response schema but no response body found) ในสถานการณ์นี้ ซึ่งบ่งชี้ว่าการตอบสนองที่คาดไว้และการตอบสนองจริงไม่ตรงกัน
  • สถานการณ์ 2:
    • ลักษณะการทำงานก่อนหน้า: หากข้อกำหนด OpenAPI ระบุอย่างชัดเจนว่าไม่คาดหวังเนื้อหาการตอบกลับ แต่การตอบกลับจริงจากนโยบายเป้าหมายหรือนโยบายต้นทางมีเนื้อหา นโยบายจะไม่ส่งผลให้เกิดข้อผิดพลาด
    • ลักษณะการทำงานปัจจุบัน: ตอนนี้นโยบายจะส่งผลให้เกิดข้อผิดพลาด (เช่น No response body is expected but one was found) ในสถานการณ์นี้ เพื่อให้มั่นใจว่าคำตอบจะเป็นไปตามสคีมาที่ระบุอย่างเคร่งครัด

การลดปัญหา

ระบุพร็อกซีหรือโฟลว์ที่แชร์ที่มีการกำหนดค่านโยบายการตรวจสอบ OAS ด้วยแท็ก Source ที่ตั้งค่าเป็น response หรือพร็อกซีหรือโฟลว์ที่ตรวจสอบการตอบกลับจากนโยบายอื่นๆ ที่สร้างการตอบกลับ

เมื่อระบุพร็อกซี/โฟลว์ที่แชร์แล้ว ให้ตรวจสอบว่าการตอบกลับและข้อกำหนด OAS สอดคล้องกัน การตอบสนองต้องสอดคล้องกับข้อกำหนด OpenAPI อย่างเคร่งครัดเกี่ยวกับการมีหรือไม่มีเนื้อหาการตอบสนอง คุณสามารถใช้การติดตาม Apigee มาตรฐานเพื่อตรวจสอบรูปแบบการเข้าชมได้ หากเป้าหมายส่งคืนการตอบกลับเป็นระยะๆ ให้ใช้นโยบายอื่นๆ เพื่อตรวจสอบก่อนนโยบาย OAS

  • หากไฟล์ข้อกำหนด OAS กำหนดเนื้อหาการตอบกลับ การตอบกลับจากนโยบายเป้าหมายหรือนโยบายต้นทางจะต้องระบุเนื้อหาการตอบกลับเสมอ
  • หากไฟล์ข้อกำหนด OAS ไม่ได้กำหนดเนื้อหาการตอบกลับ นโยบายเป้าหมายหรือนโยบายต้นทางต้องไม่ส่งเนื้อหาการตอบกลับ

อัปเดตนโยบายการตรวจสอบ OAS หรือลักษณะการทำงานเป้าหมายตามที่จำเป็นก่อนที่จะพยายามอัปเกรดเป็น Private Cloud 4.53.01 คุณควรตรวจสอบเวิร์กโฟลว์ที่ระบุไว้ดังกล่าวในสภาพแวดล้อมที่ไม่ใช่เวอร์ชันที่ใช้งานจริงก่อนเพื่อลดความเสี่ยงที่จะเกิดการหยุดชะงักระหว่างการอัปเกรดคลัสเตอร์เวอร์ชันที่ใช้งานจริง

เส้นทาง JSON

บริบท

Edge สำหรับ Private Cloud 4.53.01 ได้ทำการเปลี่ยนแปลงวิธีใช้การแสดงเส้นทาง JSON ในนโยบายต่างๆ คุณสามารถใช้นิพจน์ JSONPath ในนโยบายต่างๆ เช่น นโยบาย ExtractVariable, นโยบาย RegularExpressionProtection, การมาสก์ข้อมูล เพื่อแยกวิเคราะห์เนื้อหา JSON หรือจัดเก็บค่าในตัวแปร นอกจากนี้ คุณยังใช้นิพจน์ JSONPath ในการสร้างเทมเพลตข้อความทั่วไปเพื่อแทนที่ตัวแปรด้วยค่าแบบไดนามิกระหว่างการดำเนินการพร็อกซีได้ด้วย นิพจน์และรูปแบบ JSONPath ใหม่เป็นไปตามมาตรฐานนิพจน์ JSON ล่าสุด

การเปลี่ยนแปลง

คุณควรตรวจสอบพร็อกซี API/โฟลว์ที่แชร์ที่มีอยู่สำหรับนโยบายที่ใช้การแสดงผล JSONPath ซึ่งรวมถึงแต่ไม่จำกัดเพียงนโยบายการแยกตัวแปร นโยบายการป้องกันนิพจน์ทั่วไป หรือนโยบายใดๆ ที่มีเทมเพลตข้อความซึ่งใช้ JSONPath

ระบบใช้ข้อมูล JSON ด้านล่างเพื่ออธิบายการเปลี่ยนแปลง

{
  "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. การเปลี่ยนแปลงลักษณะการทำงานของไวลด์การ์ด JSONPath [*] สำหรับค่าออบเจ็กต์

    ลักษณะการทำงานของไวลด์การ์ด [*] มีการเปลี่ยนแปลงเมื่อใช้เพื่อเข้าถึงค่าทั้งหมดของออบเจ็กต์ JSON ก่อนหน้านี้ $.object[*] จะแสดงค่าทันทีที่อยู่ในออบเจ็กต์ JSON เดียว เมื่อใช้ไลบรารีที่อัปเดตแล้ว ตอนนี้เอาต์พุตจะเป็นอาร์เรย์ที่มีค่าเหล่านี้

    เช่น $.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"}
  ]
}
    ลักษณะการทำงานปัจจุบัน: 
    [
  [
    {"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"}]
  }
]
    การดำเนินการ:

    เปลี่ยนนิพจน์ JSONPath เพื่อกำหนดเป้าหมายออบเจ็กต์หลักอย่างง่าย (ตัวอย่าง: $.store) เพื่อกำหนดเป้าหมายรายการที่ดึงข้อมูลมาก่อนหน้านี้โดยตรง

  2. จุดต่อท้าย JSONPath (.) ในเส้นทางทำให้เกิดข้อผิดพลาด

    มีการตรวจสอบนิพจน์ JSONPath ที่เข้มงวดมากขึ้น ก่อนหน้านี้ ระบบจะเพิกเฉยต่อเส้นทางที่ลงท้ายด้วยจุดต่อท้ายที่ไม่ถูกต้อง (เช่น $.path.to.element.) โดยไม่มีการแจ้งเตือน และคําค้นหาจะยังคงแสดงผลลัพธ์หากส่วนเส้นทางที่ถูกต้องก่อนหน้าตรงกัน ในเวอร์ชันใหม่นี้ ระบบจะระบุพาธที่ผิดรูปแบบดังกล่าวว่าไม่ถูกต้องและจะทำให้เกิดข้อผิดพลาด

    ตัวอย่างเช่น $.store.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"}
]
    ลักษณะการทำงานปัจจุบัน: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    นโยบายที่มีอยู่ซึ่งใช้การแสดง JSONPath ที่มีจุดต่อท้ายโดยไม่ตั้งใจจะล้มเหลวพร้อมกับ InvalidPathException

    การดำเนินการ:

    นำจุดต่อท้ายออกจากนิพจน์ JSONPath ที่ลงท้ายด้วยจุด เช่น เปลี่ยน $.store.book. เป็น $.store.book

  3. การเปลี่ยนแปลงโครงสร้างเอาต์พุตของ(..)การลงแบบเรียกซ้ำของ JSONPath

    มีการเปลี่ยนแปลงวิธีแสดงผลลัพธ์เมื่อใช้โอเปอเรเตอร์ (..) (การสืบค้นแบบเรียกซ้ำ) เพื่อค้นหาองค์ประกอบที่มีชื่อทั้งหมด ก่อนหน้านี้ ระบบจะแปลงองค์ประกอบที่พบทั้งหมดให้เป็นรายการเดียว ตอนนี้ไลบรารีที่อัปเดตแล้วจะแสดงผลรายการของรายการ ซึ่งจะรักษาโครงสร้างการจัดกลุ่มเดิมที่มีองค์ประกอบอยู่ไว้แทนที่จะเป็นรายการแบบแบนรายการเดียว

    ตัวอย่างเช่น $..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"},
  {"author":"Abc"}
]
    ลักษณะการทำงานปัจจุบัน: 
    [
  [
    {"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"}
  ]
]
    การดำเนินการ:

    อัปเดตตรรกะการประมวลผลดาวน์สตรีมเพื่อรองรับโครงสร้างอาร์เรย์ที่ซ้อนกันใหม่ คุณอาจต้องวนซ้ำผ่าน JSONArray ด้านนอก แล้ววนซ้ำผ่าน JSONArray ด้านในแต่ละรายการเพื่อเข้าถึงองค์ประกอบแต่ละรายการ

  4. การจัดทำดัชนี JSONPath หลังจากเลือกหลายรายการหรือตัวกรองแสดงผลอาร์เรย์ว่าง

    ลักษณะการทำงานจะเปลี่ยนไปเมื่อใช้ดัชนี (เช่น [0]) ทันทีหลังจากตัวเลือกหลายรายการ (เช่น [*]) หรือตัวกรอง ([?(condition)]) ก่อนหน้านี้ นิพจน์ดังกล่าวจะพยายามเลือกรายการที่ดัชนีที่ระบุจากผลลัพธ์ที่รวมกัน ในเวอร์ชันใหม่ นิพจน์เหล่านี้จะแสดงผลอาร์เรย์ว่าง ([])

    ตัวอย่างเช่น $.store.book[*][0]

    ลักษณะการทำงานก่อนหน้า 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    ลักษณะการทำงานปัจจุบัน: 
    []
    การดำเนินการ:

    หากจำเป็นต้องกรองแล้วรับรายการที่เฉพาะเจาะจงจากชุดที่กรอง ให้ประมวลผลอาร์เรย์ที่กรองซึ่ง JSONPath ส่งคืน เช่น $..book[?(@.category == 'fiction')] แล้วใช้ [0] จากผลลัพธ์ก่อนหน้า

  5. การเปลี่ยนแปลงเอาต์พุตการแบ่งอาร์เรย์เชิงลบของ JSONPath

    เวอร์ชันใหม่ได้แก้ไขลักษณะการทำงานของการแบ่งอาร์เรย์เชิงลบ (ตัวอย่าง: [-2:], [-1:]) ก่อนหน้านี้ เมื่อใช้การแบ่งเชิงลบกับอาร์เรย์ (ระบุองค์ประกอบจากท้ายอาร์เรย์) เวอร์ชันเก่าจะแสดงเฉพาะรายการเดียวจากการแบ่งนั้นอย่างไม่ถูกต้อง ตอนนี้เวอร์ชันใหม่จะแสดงรายการ (อาร์เรย์) ที่มีองค์ประกอบทั้งหมดที่อยู่ในช่วงเชิงลบที่ระบุอย่างถูกต้อง

    เช่น $.store.book[-2:]

    ลักษณะการทำงานก่อนหน้า 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    ลักษณะการทำงานปัจจุบัน: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    การดำเนินการ:

    ตอนนี้คุณต้องอัปเดตตรรกะการประมวลผลดาวน์สตรีมเพื่อวนซ้ำอาร์เรย์ JSON ที่แสดงผลเพื่อรับเอาต์พุตที่ต้องการ

  6. จุดนำหน้า JSONPath ที่เข้มงวดขึ้น

    มีการบังคับใช้ไวยากรณ์สำหรับองค์ประกอบที่เข้าถึงได้โดยตรงจากรูทอย่างเข้มงวดมากขึ้น เมื่อเข้าถึงองค์ประกอบโดยตรงจากรูทโดยไม่มีจุดนำหน้า (เช่น $propertyelement) ตอนนี้ไวยากรณ์ดังกล่าวจะถือว่าเป็นข้อผิดพลาดและจะป้องกันการติดตั้งใช้งานพร็อกซี

    เช่น $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"}
  ]
}

    ลักษณะการทำงานในปัจจุบัน:

    Proxy will fail to deploy.

    การดำเนินการ:

    เปลี่ยน JSONPath ให้มีจุด: $.propertyName (ตัวอย่าง: $.store) วิธีนี้จะกำหนดเป้าหมายและดึงค่าได้อย่างถูกต้อง

  7. นิพจน์ JSONPath แบบไดนามิก

    โปรดอ่านนโยบายอย่างละเอียดในกรณีที่ตัวแปรเป็นตัวระบุนิพจน์ JSONPath (เช่น {myJsonPathVariable} หรือ {dynamicPath}) คุณต้องตรวจสอบค่าของตัวแปรเหล่านี้เทียบกับการเปลี่ยนแปลงด้านพฤติกรรมที่อาจเกิดขึ้นตามที่ระบุไว้ข้างต้นด้วย

การลดปัญหา

คุณต้องมีกลยุทธ์ที่ครอบคลุมเพื่อลดความเสี่ยง กระบวนการนี้เกี่ยวข้องกับการตัดสินใจเลือกเส้นทางการอัปเดตที่เหมาะสม และใช้การแก้ไขที่จำเป็นสำหรับนิพจน์ JSONPath ที่หยุดทำงาน

เลือกวิธีการอัปเกรดที่เหมาะกับคุณที่สุด

  • การย้ายข้อมูลโดยไม่มีช่วงพักการใช้งาน

    กลยุทธ์นี้เกี่ยวข้องกับการจัดหาสภาพแวดล้อมใหม่อย่างน้อย 1 รายการเพื่อให้คุณเชื่อมต่อโหนดโปรเซสเซอร์ข้อความแยกต่างหากกับสภาพแวดล้อมดังกล่าวได้ คุณสามารถตั้งค่าโหนดตัวประมวลผลข้อความดังกล่าวให้ติดตั้ง 4.53.01 และมีพร็อกซีที่มีนิพจน์ JSONPath ที่ทันสมัยได้ คุณใช้ค่าเหล่านี้ได้ในระหว่างการอัปเกรด และสามารถเลิกใช้งานได้หลังจากที่การอัปเกรดเสร็จสมบูรณ์ กลยุทธ์นี้ราบรื่น แต่ต้องจัดหาโหนดตัวประมวลผลข้อความเพิ่มเติมชั่วคราวเพื่อรองรับการอัปเกรดที่ราบรื่น รายละเอียดมีดังนี้

    • สร้างสภาพแวดล้อมใหม่และเพิ่มโหนดตัวประมวลผลข้อความใหม่เวอร์ชัน 4.53.01 ลงในสภาพแวดล้อมใหม่นี้
    • อัปโหลดแพ็กเกจพร็อกซีสำหรับพร็อกซีที่ได้รับผลกระทบไปยังสภาพแวดล้อมใหม่ และใช้การแก้ไขที่จำเป็นตามที่อธิบายไว้ในส่วนการแก้ไข แล้วจึงนำแพ็กเกจพร็อกซีที่อัปเดตแล้วไปใช้งานในสภาพแวดล้อมใหม่
    • เปลี่ยนเส้นทางการเข้าชมไปยังสภาพแวดล้อมใหม่และยกเลิกการติดตั้งใช้งานพร็อกซีที่ได้รับผลกระทบจากสภาพแวดล้อมเดิม
    • อัปเกรดโหนดตัวประมวลผลข้อความเดิมเป็น 4.53.01 ติดตั้งใช้งานพร็อกซีที่มีการแก้ไข JSONPath ในสภาพแวดล้อมเดิม
    • เปลี่ยนการรับส่งข้อมูลกลับไปที่สภาพแวดล้อมเดิม ซึ่งตอนนี้มีตัวประมวลผลข้อความใน 4.53.01 และพร็อกซีที่ได้รับการปรับปรุงให้ทันสมัยสำหรับนิพจน์ jsonpath ใหม่
    • ลบและเลิกใช้งานสภาพแวดล้อมใหม่และโหนดที่เกี่ยวข้อง
  • ช่วงพักการใช้งานและการอัปเกรด

    กลยุทธ์นี้เกี่ยวข้องกับการจัดหาช่วงหยุดทำงานสำหรับพร็อกซี API โดยใช้นิพจน์เส้นทาง JSON ที่ไม่ถูกต้อง การดำเนินการนี้ไม่จำเป็นต้องจัดหาโหนดตัวประมวลผลข้อความเพิ่มเติม แต่จะทำให้การรับส่งข้อมูล API สำหรับพร็อกซีที่ได้รับผลกระทบหยุดชะงัก

    • ระบุพร็อกซีที่ได้รับผลกระทบพร้อมนโยบายที่ได้รับผลกระทบ และสร้างการแก้ไขใหม่สำหรับพร็อกซีที่ได้รับผลกระทบทั้งหมด
    • ใช้การแก้ไขที่จำเป็นโดยใช้การแก้ไขที่อธิบายไว้ในส่วนการแก้ไขในการแก้ไขพร็อกซีครั้งใหม่ อย่าเพิ่งติดตั้งใช้งาน
    • จัดหาช่วงหยุดทำงานสำหรับพร็อกซีที่มีผลกระทบ
    • อัปเกรดตัวประมวลผลข้อความทั้งหมดเป็น Edge สำหรับ Private Cloud เวอร์ชัน 4.53.01 โปรดทราบว่าพร็อกซีที่มีอยู่อาจทำงานไม่สำเร็จในเครื่องประมวลผลข้อความที่อัปเกรดใหม่
    • เมื่ออัปเกรดตัวประมวลผลข้อความทั้งหมดเป็น Edge สำหรับ Private Cloud เวอร์ชัน 4.53.01 แล้ว ให้ติดตั้งใช้งานการแก้ไขพร็อกซีที่สร้างขึ้นใหม่ด้วยนิพจน์ JSONPath ที่แก้ไขแล้ว
    • เรียกใช้การรับส่งข้อมูลบนพร็อกซีดังกล่าวต่อ
  • ออกแบบพร็อกซีใหม่ก่อนอัปเกรด

    คุณสามารถออกแบบพร็อกซีใหม่ก่อนอัปเกรดเป็น Edge for Private Cloud 4.53.01 คุณสามารถรับผลลัพธ์เดียวกันได้โดยใช้วิธีอื่นแทนการใช้การแสดงเส้นทาง JSON ที่เฉพาะเจาะจง

    เช่น หากคุณใช้นโยบาย Extract Variable กับเส้นทาง JSON คุณสามารถแทนที่นโยบายด้วยนโยบาย JavaScript ที่ดึงข้อมูลที่คล้ายกันก่อนที่จะอัปเกรดเป็นเวอร์ชันใหม่กว่า หลังจากอัปเกรดเสร็จสมบูรณ์แล้ว คุณสามารถเปลี่ยนพร็อกซีกลับไปใช้เส้นทาง JSON กับรูปแบบใหม่กว่าได้

การเปลี่ยนแปลง JavaCallout

บริบท

Edge สำหรับ Private Cloud 4.53.00 และเวอร์ชันก่อนหน้าเคยมีไดเรกทอรีชื่อ deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) ซึ่งมีไลบรารี JAR จำนวนมาก ไลบรารีเหล่านี้พร้อมให้ใช้งานในโค้ด Java ในนโยบาย JavaCallout และโค้ด Java ที่กำหนดเองอาจใช้ไลบรารีเหล่านี้โดยตรงหรือโดยอ้อม

การเปลี่ยนแปลง

ตอนนี้เราได้นำไดเรกทอรีที่เลิกใช้งานแล้วออกใน Edge สำหรับ Private Cloud เวอร์ชัน 4.53.01 ในกรณีที่โค้ด Java ของคุณต้องใช้ไลบรารีดังกล่าว พร็อกซีที่ใช้การเรียก Java ดังกล่าวจะล้มเหลวเมื่ออัปเกรด Message Processor เป็นเวอร์ชัน 4.53.01 หากต้องการหลีกเลี่ยงความล้มเหลวดังกล่าว ให้ทำตามขั้นตอนการลดความเสี่ยงด้านล่างก่อนอัปเกรดโปรแกรมประมวลผลข้อความเป็นเวอร์ชัน 4.53.01

การลดปัญหา

  1. ตรวจสอบนโยบาย Java-Callout และไฟล์ JAR ที่เกี่ยวข้อง แล้วดูว่านโยบายหรือไฟล์ JAR เหล่านั้นอ้างอิงหรือใช้ไลบรารีใดๆ ที่อยู่ในไดเรกทอรี "เลิกใช้งานแล้ว" ของ Message Processor ปัจจุบันหรือไม่ โปรดทราบว่าการเรียกใช้ Java อาจใช้ไฟล์ JAR ที่อัปโหลดเป็นทรัพยากรระดับองค์กรหรือสภาพแวดล้อม ลองพิจารณาไลบรารีเหล่านี้ด้วย
  2. เมื่อระบุไลบรารีที่เลิกใช้งานแล้วดังกล่าวได้ คุณสามารถใช้วิธีใดวิธีหนึ่งต่อไปนี้เพื่อลดปัญหา
    • การวางทรัพยากร (แนะนำหากคุณมีไฟล์ JAR / ไลบรารีจำนวนเล็กน้อยจากไดเรกทอรีที่เลิกใช้งานแล้วซึ่งไฟล์ JAR ของ Java-Callout อ้างอิงอยู่)
      • อัปโหลดไฟล์ JAR ที่เลิกใช้งานแล้วซึ่งระบุเป็นทรัพยากรในระดับที่ต้องการ ได้แก่ การแก้ไขพร็อกซี API, สภาพแวดล้อม หรือองค์กร
      • ดำเนินการอัปเกรดซอฟต์แวร์ Apigee ตามปกติ
    • ตำแหน่งแบบกำหนดเอง (แนะนำหากคุณมีไฟล์ JAR / ไลบรารีจำนวนมากที่ไฟล์ JAR ของ Java-Callout อ้างอิง)
      • สร้างไดเรกทอรีใหม่ชื่อ external-lib ในเส้นทาง $APIGEE_ROOT/data/edge-message-processor/ ในโหนดตัวประมวลผลข้อความแต่ละรายการ
      • คัดลอกไฟล์ JAR ที่ระบุไปยังไดเรกทอรี external-lib นี้จากไดเรกทอรีที่เลิกใช้งานแล้ว cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • ตรวจสอบว่าผู้ใช้ Apigee อ่านไดเรกทอรีและไฟล์ JAR ที่เกี่ยวข้องได้: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • ดำเนินการอัปเกรดซอฟต์แวร์ Apigee ตามปกติ

การเปลี่ยนแปลง OpenLDAP

บริบท

คุณใช้ OpenLDAP ใน Edge Private Cloud ได้ทั้งสำหรับการตรวจสอบสิทธิ์และการให้สิทธิ์ ใน Edge สำหรับ Private Cloud 4.53.01 ซอฟต์แวร์ OpenLDAP ที่จัดส่งโดย Apigee ได้รับการอัปเกรดจากเวอร์ชัน 2.4 เป็น 2.6

การเปลี่ยนแปลง

ใน OpenLDAP 2.6 ชื่อเฉพาะแบบสัมพัทธ์ (RDN) จะจำกัดไว้ที่ประมาณ 241 ไบต์/อักขระ ข้อจำกัดนี้เป็นขีดจำกัดสูงสุดที่บังคับใช้และแก้ไขไม่ได้

ผลกระทบ
  • การจำลองหรือการนำเข้าล้มเหลวสำหรับรายการที่มี RDN ขนาดใหญ่เกินไป
  • การพยายามสร้างเอนทิตี เช่น องค์กร สภาพแวดล้อม บทบาทที่กำหนดเอง สิทธิ์ ฯลฯ อาจทำให้เกิดข้อความแสดงข้อผิดพลาด: "message": "[LDAP: error code 80 - Other]"
  • DN ที่ยาวกว่า 241 ไบต์ใน LDAP ของ Apigee จะได้รับผลกระทบ DN ดังกล่าวจะทําให้อัปเกรดซอฟต์แวร์ Apigee OpenLDAP ไม่สําเร็จ และคุณจะต้องทํากลยุทธ์การลดความเสี่ยงสําหรับรายการดังกล่าวก่อนจึงจะดําเนินการอัปเกรดต่อได้

โดยทั่วไปใน LDAP ของ Apigee นั้น DN ที่ยาวจะเกี่ยวข้องกับสิทธิ์เนื่องจากสร้างขึ้นโดยการต่อเอนทิตีหลายรายการ รายการสิทธิ์ดังกล่าวมีแนวโน้มที่จะเกิดปัญหาในการอัปเกรดเป็นพิเศษ

ตัวอย่างเช่น 

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

โดยปกติแล้ว คุณจะมีชื่อองค์กร สภาพแวดล้อม และบทบาทที่มีความยาวซึ่งทำให้ RDN ใน LDAP มีขนาดเล็กกว่า 241 ไบต์

การลดปัญหา

ก่อนอัปเกรดเป็น 4.53.01:

ขั้นตอนต่อไปนี้จะช่วยยืนยันการมีอยู่ของ RDN แบบยาวในคลัสเตอร์ LDAP 2.4 ที่มีอยู่

#1 - ดึงข้อมูล LDAP

ใช้คำสั่ง ldapsearch เพื่อค้นหาชื่อเฉพาะ (dn) และเปลี่ยนเส้นทางเอาต์พุตไปยังไฟล์ 

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

ตรวจสอบว่าไฟล์ DN.ldif ด้านบนมีรายการ LDAP

#2 - ระบุ RDN ที่ยาว

ค้นหา RDN ที่เกิน 241 ไบต์/อักขระจากไฟล์ DN.ldif ด้านบน

cat /tmp/DN.ldif |  grep '^dn:' | gawk -F',|dn: ' '{ rdn = $2; char_count = length(rdn); cmd = "echo -n \"" rdn "\" | wc -c"; cmd | getline byte_count; close(cmd); if (char_count > 241 || byte_count > 241) { print rdn, "(chars: " char_count ") (bytes: " byte_count ")"; }}'
o=VeryLongOrgNameWithMoreThan241Chars.... (chars: 245) (bytes: 245)
cn=VeryLongCustomRoleNameWithMoreThan241Chars.... (chars: 258) (bytes: 258)

หากคำสั่งข้างต้นไม่สร้างเอาต์พุต แสดงว่าไม่มี RDN ในการตั้งค่า LDAP ที่มีอยู่ซึ่งเกิน 241 ไบต์/อักขระ คุณสามารถดำเนินการอัปเกรดต่อได้ตามปกติ

หากคำสั่งข้างต้นสร้างเอาต์พุต แสดงว่ามี RDN ที่เกิน 241 ไบต์/อักขระ สำหรับรายการดังกล่าว ให้ทำตามขั้นตอนการลดความเสี่ยงตามที่อธิบายไว้ในขั้นตอนที่ 3 ก่อนดำเนินการอัปเกรด Edge for Private Cloud 4.53.01

#3 - จัดการ RDN ที่มีความยาว

หากได้รับเอาต์พุตจากขั้นตอนที่ 2 แสดงว่ามี RDN ที่ยาวเกิน 241 ไบต์/อักขระ ให้ทำตามขั้นตอนการลดความเสี่ยงด้านล่าง

ตรวจสอบรายการ LDAP ที่มีขนาดเกิน 241 ไบต์

  • หากเป็นชื่อบทบาทที่กำหนดเอง แอป ผลิตภัณฑ์ API หรือเอนทิตีอื่นๆ ซึ่งเป็นปัจจัยหลักที่ทำให้ RDN ยาว ให้ย้ายข้อมูลไปใช้เอนทิตีอื่นที่มีชื่อสั้นกว่า
  • หากชื่อองค์กรหรือชื่อสภาพแวดล้อมเป็นปัจจัยหลักที่ทำให้ RDN ยาว คุณจะต้องย้ายข้อมูลไปยังองค์กรหรือสภาพแวดล้อมอื่นที่มีชื่อสั้นกว่า

ทำขั้นตอนข้างต้นซ้ำจนกว่า LDAP จะไม่มี RDN ที่ยาวเกิน 241 ไบต์ เมื่อถึงสถานะนี้แล้ว ให้ดำเนินการอัปเกรดเวอร์ชันของ Private Cloud ตามปกติ

การเปลี่ยนแปลงผู้ให้บริการด้านการเข้ารหัส

บริบท

การเปลี่ยนแปลงนี้เป็นการเปลี่ยนแปลงต่อเนื่องจาก Edge สำหรับ Private Cloud 4.53.00 ใน Edge for Private Cloud 4.53.00 มีการอัปเดตผู้ให้บริการการเข้ารหัสภายในจาก Bouncy Castle (BC) เป็น Bouncy Castle FIPS (BCFIPS) เพื่อเปิดใช้การรองรับ FIPS

การเปลี่ยนแปลง

หากนโยบาย JavaCallout อาศัยการใช้ผู้ให้บริการ BC เดิม โดยเฉพาะเมื่อใช้ฟังก์ชันความปลอดภัยที่ได้รับการเสริมความแข็งแกร่งในผู้ให้บริการ BCFIPS (เช่น การใช้คู่คีย์ทั่วไปสำหรับการเข้ารหัสและการลงนาม) คุณจะต้องปรับปรุงนโยบาย JavaCallout ดังกล่าว นโยบาย JavaCallout ที่พยายามโหลดผู้ให้บริการการเข้ารหัส Bouncy Castle โดยใช้ชื่อ BC อาจล้มเหลวเนื่องจากผู้ให้บริการเริ่มต้นมีการเปลี่ยนแปลง นโยบายดังกล่าวที่ใช้ผู้ให้บริการ BC อาจหยุดทำงานในภายหลัง การติดตั้งใช้งานที่กำหนดเองซึ่งอิงตามผู้ให้บริการ BC รายเดิมจะเข้าถึงไม่ได้อีกต่อไป และจะต้องได้รับการตรวจสอบและติดตั้งใช้งานใหม่

การลดปัญหา

วิธีแก้ปัญหาที่แนะนำคือการใช้ผู้ให้บริการ BCFIPS การติดตั้งใช้งาน JavaCallout ที่กำหนดเองซึ่งอิงตามผู้ให้บริการรายเก่าจะต้องได้รับการตรวจสอบและติดตั้งใช้งานอีกครั้งโดยใช้ผู้ให้บริการ FIPS ของ Bouncy Castle ซึ่งเข้าถึงได้โดยใช้สตริง "BCFIPS"

เครื่องมือตรวจหาการเปลี่ยนแปลงอัตโนมัติ

เราวางแผนที่จะเปิดตัวเครื่องมือตรวจหาการเปลี่ยนแปลงในเร็วๆ นี้ เครื่องมือนี้จะมีความสามารถในการสแกนและระบุพร็อกซี API, โฟลว์ที่ใช้ร่วมกัน, ทรัพยากร และ RDN ของ LDAP ที่อาจได้รับผลกระทบจากการเปลี่ยนแปลงต่างๆ ที่อธิบายไว้ในบทความนี้ เครื่องมือนี้จะช่วยในการระบุเอนทิตีต่างๆ ที่มีแนวโน้มที่จะล้มเหลวระหว่างหรือหลังการอัปเกรดเป็น Edge for Private Cloud 4.53.01