OkHttp Basic პროქსის ავთენტიფიკაცია: შეწყვიტეთ უარყოფილი გამეორებები

Basic ავთენტიფიკაციის შემომთავაზებელი HTTP პროქსისთვის OkHttp-ის proxyAuthenticator შეიძლება დააბრუნოს მოწმობების მატარებელი მოთხოვნა. დააბრუნეთ null მას შემდეგ, რაც ავტორიზაციის მცდელობა უკვე უარყოფილია, იმის ნაცვლად, რომ იგივე პასუხი კვლავ გაგზავნოთ:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

ეს ესკიზი იყენებს ანგარიშის მნიშვნელობებს აპლიკაციის საიდუმლო კონფიგურაციიდან. დამცავი რთავს პირველ მცდელობას და აჩერებს გამეორებულს. ის ახორციელებს Basic-ს, და არა ყველა სქემას, რომლის რეკლამირებაც პროქსის შეუძლია; შეამოწმეთ გამოწვევა ამ პასუხის არჩევამდე.

თუ საბოლოო შედეგი კვლავ 407 არის, შეადარეთ არჩეული პროქსი, გამოცხადებული სქემა და დოკუმენტირებული ანგარიშის იდენტობა. უარყოფილი პაროლი, მხარდაუჭერელი მეთოდი და მომხმარებლის სახელის არასწორი ფორმა სხვადასხვა შესწორებას მოითხოვს. შეინახეთ ეს დაკვირვებები და საბოლოო სტატუსი რედაქტირებულ დიაგნოსტიკაში.

CONNECT-ს სხვა callback კონტექსტი აქვს: OkHttp ადოკუმენტებს სინთეტიკურ პრეემპტიურ პროქსის ავთენტიფიკაციის გამოწვევას გვირაბის გახსნამდე. მართეთ ეს კონტექსტი API-ის მიხედვით, იმის ნაცვლად, რომ ჩათვალოთ ყოველი callback ჩვეულებრივ დანიშნულების პასუხად.

ცალკე authenticator განკუთვნილია დანიშნულების სერვერის ავთენტიფიკაციისთვის. შეინახეთ მისი მოწმობები პროქსის შესვლისგან განცალკევებით; ზოგადი ინტერსეპტორი, რომელიც პროქსის პაროლს ყოველ გამავალ მოთხოვნაზე აყენებს, შეიძლება გაგზავნოს ის არასწორ არეალში.

ისტორიული მოხსენებები ასევე აღწერენ იმპლემენტაციის ხარვეზებს, მათ შორის უარყოფილი პროქსის პასუხის სხეულის დამუშავებას. ჩაწერეთ OkHttp-ის ვერსია და საბოლოო გაცვლა, სანამ მიმდინარე წარუმატებლობას ძველ მოხსენებას მიაწერთ. გამეორების გადაწყვეტილებამ კვლავ უნდა შეაჩეროს უცვლელი მოწმობების მცდელობა, რომელსაც არ აქვს სასარგებლო ახალი პასუხი.