Պահոցային հաճախորդի HTTP տրանսպորտում պրոքսի կարգավորումը պատասխանում է մեկ հարցի՝ ինչպես է այդ տրանսպորտն ուղարկում պահոցային հարցումները։ Ինքնության վկայականը կարող է ունենալ մեկ այլ HTTP հաճախորդ՝ token-ներ ստանալու համար։

Այդ տարբերությունը բացատրում է թվացյալ սովորական հակասություն՝ պահոցի վերջնակետը հասանելի է պրոքսիով, բայց SDK-ն ձախողվում է սպասվող գործողությունն ուղարկելուց առաջ։ Ձախողումը կարող է վերաբերել ինքնության վերջնակետից վկայական ստանալուն։

Նախ գրանցեք, թե որ նպատակակետն է ձախողվել։ Այնուհետև ստուգեք պահոցի կառուցիչին տրված HTTP հաճախորդը և վկայականի իրականացման օգտագործած կարգավորումը։ Հետևեք յուրաքանչյուր տրանսպորտի աջակցվող պրոքսի ընտրանքներին։ Թույլատրված հանրային պրոքսի երթուղու վրա հանրությանը հասանելի պահոցի և token-ի վերջնակետերի համար HTTP պրոքսիների ցանկը առաջարկում է վերջնակետի թեկնածուներ. մի՛ ենթադրեք, որ մեկ կառուցիչի կարգավորումը վերակարգավորում է հավելվածի յուրաքանչյուր օբյեկտ։

ՓուլՕգտակար ապացույց
Token-ի ստացումԻնքնության վերջնակետ, ընտրված հաճախորդ, պրոքսի մարտահրավեր կամ միացման սխալ
Պահոցային հարցումՊահոցի վերջնակետ, կարգավորված խողովակաշար, վերջնական պատասխան կամ փոխանցման ձախողում

Պրոքսի հաշիվը առանձին պահեք Azure-ի վկայականից։ Հաջող պրոքսի մուտքը տալիս է երթուղի. նպատակակետ ծառայությունը դեռ լիազորում է Azure գործողությունը։

Պատմական պատասխանները օգտագործում են Azure Storage Java դասերի մի քանի սերունդ, ներառյալ հին OperationContext և խողովակաշարի API-ները։ Համապատասխանեցրեք օրինակը հավելվածի ներկայիս SDK-ին և HTTP տրանսպորտին։ Data Lake SDK-ի համար պահոցի և ինքնության համատեղ HTTP հաճախորդի կարգավորումը ցույց է տալիս կառուցիչի երկու մուտքերը։ Հնացած հաճախորդի տիպը պրոքսի խնդիրը լուծելու համար վերաներկայացնելը ստեղծում է ևս մեկ կարգավորման ուղի՝ վրիպազերծելու համար։

Մատյաններում օգտագործեք անվտանգ վերջնակետի նույնացուցիչներ։ Պահոցի URL-ները կարող են պարունակել մուտքի token-ներ, իսկ ամբողջական պրոքսի URL-ը կարող է պարունակել գաղտնաբառ։

Առնչվող հոդվածներ