ورود به پروکسی متعلق به تأمین‌کننده اعتبارنامه انتقال است. با Spring 6 و Apache HttpClient 5، آن حساب را به واسطه محدود کنید:

var proxy = new org.apache.hc.core5.http.HttpHost(
    "http", "proxy.example", 8080);
var credentials = new org.apache.hc.client5.http.impl.auth
    .BasicCredentialsProvider();
credentials.setCredentials(
    new org.apache.hc.client5.http.auth.AuthScope(proxy),
    new org.apache.hc.client5.http.auth.UsernamePasswordCredentials(
        proxyUser, proxyPassword.toCharArray()));

var http = org.apache.hc.client5.http.impl.classic.HttpClients.custom()
    .setProxy(proxy)
    .setDefaultCredentialsProvider(credentials)
    .build();
var factory = new org.springframework.http.client
    .HttpComponentsClientHttpRequestFactory(http);
var rest = new org.springframework.web.client.RestTemplate(factory);

برنامه مقادیر proxyUser و proxyPassword را فراهم می‌کند و مالک چرخه عمر کلاینت HTTP است. به جای ساختن قالبی پیش‌فرض دیگر در محل فراخوانی، از rest برای بار کاری دوباره استفاده کنید.

AuthScope محدود می‌کند که این اعتبارنامه کجا معتبر است. مثال اعتبارنامه معمول نام کاربری/گذرواژه را فراهم می‌کند؛ نام BasicCredentialsProvider هر چالشی را مجبور به استفاده از طرح HTTP Basic نمی‌کند.

با مقصد HTTPS، انتقال می‌تواند در زمان CONNECT به چالش پروکسی پاسخ دهد، پیش از آنکه درخواست HTTP رمزنگاری‌شده برنامه وجود داشته باشد. یک رهگیر مقصد عمومی که Proxy-Authorization را اضافه می‌کند معادل آن مذاکره نیست.

هر حساب مقصد را جداگانه پیکربندی کنید. اگر پروکسی هنوز درخواست را رد می‌کند، طرح احراز هویتی که اعلام می‌کند و میزبان و درگاه مؤثر را نگه دارید. اعتبارنامه محدود به نقطه پایانی دیگر فقط به این دلیل که گذرواژه درست است مطابقت نخواهد کرد.

مقالات مرتبط