REST Assured अनुरोध के लिए बेसिक प्रॉक्सी प्रमाणीकरण
मध्यस्थ के पते और खाते के लिए ProxySpecification का उपयोग करें, और भरोसा कॉन्फ़िगरेशन HTTPS क्लाइंट पर ही रखें।
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 क्लाइंट की भरोसा व्यवस्था में नहीं है, तो उसे स्वीकृत प्रशासनिक माध्यम से प्राप्त करें और परीक्षण क्लाइंट का truststore कॉन्फ़िगर करें।
REST Assured इस उद्देश्य के लिए trustStore प्रदान करता है। truststore बदलता है कि HTTPS क्लाइंट किन जारीकर्ताओं पर भरोसा करता है; यह प्रॉक्सी नहीं चुनता और न ही उसका लॉगिन देता है। जो भी प्रमाणपत्र प्रस्तुत हो उसे स्वीकार करने के लिए accept-all हैंडशेक का उपयोग करने के बजाय होस्टनाम और प्रमाणपत्र सत्यापन चालू रखें।