Сактоо кардарынын HTTP транспортунда прокси конфигурациялоо бир суроого жооп берет: ал транспорт сактоо сурамдарын кантип жөнөтөт. Идентификация credentialинде токен алуу үчүн башка HTTP кардар болушу мүмкүн.

Бул айырма көп кездешкендей көрүнгөн карама-каршылыкты түшүндүрөт: сактоо endpointине прокси аркылуу жетүүгө болот, бирок SDK күтүлгөн операцияны жөнөтө электе эле ишке ашпайт. Ийгиликсиздик идентификация endpointине каршы credential алууга тиешелүү болушу мүмкүн.

Алгач кайсы максат ийгиликсиз болгонун жазыңыз. Андан кийин сактоо куруучусуна берилген HTTP кардарды жана credential ишке ашыруусу колдонгон конфигурацияны карап чыгыңыз. Ар бир транспорттун колдоого алынган прокси параметрлерин аткарыңыз. Уруксат берилген коомдук прокси маршрутундагы коомчулукка жеткиликтүү сактоо жана токен endpointтери үчүн HTTP прокси тизмеси endpoint талапкерлерин сунуштайт; бир куруучунун жөндөөсү тиркемедеги ар бир объектини кайра конфигурациялайт деп ойлобоңуз.

БаскычПайдалуу далил
Токен алууИдентификация endpointи, тандалган кардар, прокси чакырыгы же туташуу катасы
Сактоо сурамыСактоо endpointи, конфигурацияланган түтүк, акыркы жооп же өткөрүү ийгиликсиздиги

Прокси эсебин Azure credentialинен өзүнчө кармаңыз. Проксиге ийгиликтүү кирүү маршрут берет; максаттык кызмат Azure операциясына уруксат берүүнү улантат.

Тарыхый жооптор Azure Storage Java класстарынын бир нече муунун, анын ичинде эски OperationContext жана түтүк APIлерин колдонот. Мисалды тиркеме азыр колдонгон SDK жана HTTP транспорту менен дал келтириңиз. Data Lake SDK үчүн сактоо жана идентификация үчүн жалпы HTTP кардар конфигурациясы куруучунун эки кирүүсүн көрсөтөт. Прокси көйгөйүн чечүү үчүн эскирген кардар түрүн кайра киргизүү мүчүлүштүктү оңдоонун дагы бир конфигурация жолун түзөт.

Журналдарда коопсуз endpoint идентификаторлорун колдонуңуз. Сактоо URLдеринде кирүү токендери, ал эми толук прокси URLинде сырсөз болушу мүмкүн.

Тектеш макалалар