Հիմնական պրոքսի նույնականացում 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 արժեքները իր սովորական հավատարմագրերի աղբյուրից։ Այս հատվածը կառուցում է հարցման ճշգրտում․ նպատակային API URL-ը կանչեք request-ի միջոցով՝ թեստի սովորական հարցման և ստուգման կոդով։

http սխեման նկարագրում է պրոքսիի վերջնակետը։ API URL-ը կարող է մնալ HTTPS։ REST Assured-ի withAuth մեխանիզմը տրամադրում է հիմնական պրոքսի նույնականացում․ այն չի բանակցում բոլոր կորպորատիվ նույնականացման սխեմաների հետ միայն այն պատճառով, որ տրվել են երկու տող։

API-ի հավատարմագրերը տեղադրեք API-ի սեփական նույնականացման կարգավորման մեջ։ Խուսափեք պրոքսի հաշիվը ընդհանուր Authorization վերնագրով կամ ծառայության գաղտնաբառով փոխարինելուց։ HTTPS-ի դեպքում միջնորդի հետ նույնականացումը կարող է անհրաժեշտ լինել CONNECT-ը հաստատելիս, մինչև նպատակակետի հետ HTTP փոխանակումը գոյություն ունենա։

Երբ մնացած ձախողումը վկայագրի վստահությունն է

Մերժված CONNECT մարտահրավերը և TLS վկայագրի վավերացման սխալը տարբեր արդյունքներ են։ Եթե պահանջվող կազմակերպության կողմից կառավարվող CA-ն բացակայում է հաճախորդի վստահության կարգավորումից, ստացեք այն հաստատված վարչական ուղով և կարգավորեք թեստային հաճախորդի truststore-ը։

REST Assured-ը այդ նպատակով տրամադրում է trustStore։ Truststore-ը փոխում է, թե որ թողարկողներին է վստահում HTTPS հաճախորդը․ այն չի ընտրում պրոքսին և չի տրամադրում դրա մուտքը։ Թողեք հոսթի անվան և վկայագրի վավերացումը միացված՝ accept-all ձեռքսեղմում օգտագործելու փոխարեն, որը կընդունի ներկայացված ցանկացած վկայագիր։