REST Assured অনুরোধের জন্য মৌলিক প্রক্সি প্রমাণীকরণ

REST Assured-এ একটি প্রক্সি স্পেসিফিকেশন আছে যা মধ্যস্থতাকারীর ঠিকানা ও শংসাপত্র একসঙ্গে বহন করে:

import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;

var proxy = ProxySpecification.host("proxy.example")
    .withPort(8080)
    .withScheme("http")
    .withAuth(proxyUser, proxyPassword);

var request = given().proxy(proxy);

অ্যাপ্লিকেশনটি তার স্বাভাবিক শংসাপত্র উৎস থেকে proxyUser এবং proxyPassword সরবরাহ করে। অংশটি একটি অনুরোধ স্পেসিফিকেশন তৈরি করে; পরীক্ষার স্বাভাবিক অনুরোধ ও যাচাই কোড ব্যবহার করে request-এর মাধ্যমে লক্ষ্য API URL ডাকুন।

http স্কিম প্রক্সির প্রান্তবিন্দু বর্ণনা করে। API URL HTTPS-ই থাকতে পারে। REST Assured-এর withAuth ব্যবস্থা মৌলিক প্রক্সি প্রমাণীকরণ সরবরাহ করে; শুধু দুটি স্ট্রিং দেওয়া হয়েছে বলে এটি সব কর্পোরেট প্রমাণীকরণ স্কিম নিয়ে দরকষাকষি করে না।

API-র শংসাপত্র API-র নিজের প্রমাণীকরণ কনফিগারেশনে রাখুন। প্রক্সি অ্যাকাউন্টের বদলে সাধারণ Authorization হেডার বা সার্ভিস পাসওয়ার্ড ব্যবহার করা এড়িয়ে চলুন। HTTPS-এ CONNECT স্থাপনের সময়, গন্তব্যের HTTP বিনিময় হওয়ার আগেই মধ্যস্থতাকারীর সঙ্গে প্রমাণীকরণের দরকার হতে পারে।

যখন অবশিষ্ট ব্যর্থতা শংসাপত্রের বিশ্বাস

প্রত্যাখ্যাত CONNECT চ্যালেঞ্জ আর একটি TLS শংসাপত্র যাচাই ত্রুটি আলাদা ফলাফল। প্রয়োজনীয় প্রতিষ্ঠান-পরিচালিত CA যদি ক্লায়েন্টের বিশ্বাস ব্যবস্থায় না থাকে, অনুমোদিত প্রশাসনিক চ্যানেলে সেই CA নিন এবং পরীক্ষা ক্লায়েন্টের truststore কনফিগার করুন।

REST Assured এই উদ্দেশ্যে trustStore দেয়। truststore বদলে দেয় HTTPS ক্লায়েন্ট কোন ইস্যুয়ারকে বিশ্বাস করবে; এটি প্রক্সি বেছে নেয় না বা তার লগইন দেয় না। accept-all হ্যান্ডশেক ব্যবহার করে যা-ই শংসাপত্র দেওয়া হোক তা নেওয়ার বদলে হোস্টনাম ও শংসাপত্র যাচাই চালু রাখুন।