Наладка проксі на HTTP-транспарце кліента сховішча адказвае на адно пытанне: як гэты транспарт адпраўляе запыты да сховішча. Уліковыя дадзеныя ідэнтычнасці могуць мець іншы HTTP-кліент для атрымання токенаў.

Гэтае адрозненне тлумачыць звычайную на выгляд супярэчнасць: канчатковы пункт сховішча дасягальны праз проксі, але SDK падае яшчэ да адпраўкі чаканай аперацыі. Збой можа адносіцца да атрымання ўліковых дадзеных на канчатковым пункце ідэнтычнасці.

Спачатку зафіксуйце, які мэтавы адрас не спрацаваў. Затым агледзьце HTTP-кліент, перададзены будаўніку сховішча, і канфігурацыю, якую выкарыстоўвае рэалізацыя ўліковых дадзеных. Ідзіце па падтрыманых параметрах проксі кожнага транспарту. Для публічна дасягальных канчатковых пунктаў сховішча і токенаў на дазволеным маршруце публічнага проксі спіс HTTP-проксі прапануе кандыдаты канчатковых пунктаў; не мяркуйце, што наладка аднаго будаўніка перанастроіць кожны аб’ект у праграме.

ЭтапКарысныя доказы
Атрыманне токенаКанчатковы пункт ідэнтычнасці, выбраны кліент, выклік проксі або памылка злучэння
Запыт да сховішчаКанчатковы пункт сховішча, наладжаны канвеер, канчатковы адказ або збой перадачы

Трымайце ўліковы запіс проксі асобна ад уліковых дадзеных Azure. Паспяховы ўваход у проксі дае маршрут; служба прызначэння ўсё яшчэ аўтарызуе аперацыю Azure.

Гістарычныя адказы выкарыстоўваюць некалькі пакаленняў класаў Azure Storage Java, у тым ліку старыя API OperationContext і канвеера. Супастаўце прыклад з SDK і HTTP-транспартам, якія зараз выкарыстоўвае праграма. Для SDK Data Lake агульная наладка HTTP-кліента для сховішча і ідэнтычнасці паказвае абодва ўваходы будаўніка. Вяртанне састарэлага тыпу кліента для рашэння праблемы проксі стварае яшчэ адзін шлях канфігурацыі для адладкі.

Выкарыстоўвайце бяспечныя ідэнтыфікатары канчатковых пунктаў у журналах. URL сховішча могуць змяшчаць токены доступу, а поўны URL проксі можа змяшчаць пароль.

Падобныя артыкулы