መሠረታዊ የፕሮክሲ ማረጋገጫ ለ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 ን ከተለመደው የማስረጃ ምንጩ ያቀርባል። ይህ ክፍል የጥያቄ ዝርዝር ይገነባል፤ የታሰበውን API URL በ request በመጠቀም በፈተናው መደበኛ የጥያቄና የማረጋገጫ ኮድ ይጥሩ።
የ 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 ማገናኘትን ከመጠቀም ይልቅ የአስተናጋጅ ስምና የምስክር ወረቀት ማረጋገጫን አብራ ያቆዩ።