პროქსის ძირითადი ავთენტიფიკაცია 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 ხელის ჩამორთმევა წარმოდგენილი ნებისმიერი სერტიფიკატის მისაღებად.