Azure Storage Java: прокси руте за API и захтеве за токенима
Проверите и захтеве за Azure Storage и захтеве за токенима акредитива када конфигуришете прокси за Java SDK.
Конфигурисање проксија на HTTP транспорту клијента за складиштење одговара на једно питање: како тај транспорт шаље захтеве за складиштење. Акредитив идентитета може имати други HTTP клијент за добијање токена.
Та разлика објашњава наизглед уобичајену противречност: крајња тачка складиштења је доступна кроз прокси, али SDK пада пре слања очекиване операције. Неуспех може припадати добијању акредитива према крајњој тачки идентитета.
Најпре забележите које одредиште није успело. Затим прегледајте HTTP клијент предат градитељу складиштења и конфигурацију коју користи имплементација акредитива. Пратите подржане прокси опције сваког транспорта. За јавно доступне крајње тачке складиштења и токена на дозвољеној јавној прокси рути списак HTTP проксија нуди кандидате за крајње тачке; не претпостављајте да поставка једног градитеља реконфигурише сваки објекат у апликацији.
| Фаза | Корисни докази |
|---|---|
| Добијање токена | Крајња тачка идентитета, изабрани клијент, изазов проксија или грешка везе |
| Захтев за складиштење | Крајња тачка складиштења, конфигурисани ток, коначни одговор или неуспех преноса |
Држите налог проксија одвојено од Azure акредитива. Успешна пријава на прокси даје руту; услуга одредишта и даље одобрава Azure операцију.
Историјски одговори користе неколико генерација Azure Storage Java класа, укључујући старије OperationContext и pipeline API. Ускладите пример са SDK-ом и HTTP транспортом које апликација сада користи. За Data Lake SDK заједничко подешавање HTTP клијента за складиштење и идентитет приказује оба улаза градитеља. Поновно увођење застарелог типа клијента ради решавања прокси проблема ствара још једну путању конфигурације за отклањање грешака.
Користите безбедне идентификаторе крајњих тачака у дневницима. URL-ови складиштења могу садржати приступне токене, а потпуни прокси URL може садржати лозинку.