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 ക്ലൈന്റിന്റെ വിശ്വാസ ക്രമീകരണത്തിൽ ഇല്ലെങ്കിൽ, അംഗീകൃത ഭരണപരമായ ചാനലിലൂടെ അത് നേടി ടെസ്റ്റ് ക്ലൈന്റിന്റെ truststore ക്രമീകരിക്കുക.

ആ ആവശ്യത്തിനായി REST Assured trustStore നൽകുന്നു. truststore, HTTPS ക്ലൈന്റ് ഏത് ഇഷ്യൂവർമാരെ വിശ്വസിക്കുന്നു എന്ന് മാറ്റുന്നു; അത് പ്രോക്സി തിരഞ്ഞെടുക്കുന്നില്ല, അതിന്റെ ലോഗിൻ നൽകുന്നുമില്ല. അവതരിപ്പിക്കുന്ന ഏതെങ്കിലും സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കാൻ accept-all ഹാൻഡ്ഷേക്ക് ഉപയോഗിക്കുന്നതിന് പകരം ഹോസ്റ്റ്നാമവും സർട്ടിഫിക്കറ്റും പരിശോധിക്കുന്നത് സജീവമായി നിർത്തുക.