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 હેન્ડશેક વાપરવાને બદલે હોસ્ટનામ અને પ્રમાણપત્ર ચકાસણી ચાલુ રાખો.