Դոմենով որակավորված օգտանուններ պրոքսիի հավատարմագրերում
Տարբերե՛ք անթափանց հաշվի անունը առանձին դոմեն դաշտերով API-ներից և խուսափե՛ք հաշվի ինքնությունը փոխելուց միայն URL-ի շարահյուսության համար։
Մի պատասխան ասում է հեռացնել DOMAIN\։ Մյուսն ասում է ավելացնել այն։ Երկու փոփոխություններն էլ կարող են սխալ լինել ձեր պրոքսիի համար։
Երկու հարց կա՝ ո՞ր ինքնությունն է սպասում ծառայությունը, և ինչպե՞ս է ընտրված API-ն ներկայացնում այդ ինքնությունը։
| Ինտերֆեյս | Ինչ պետք է պարզել |
|---|---|
| Մեկ հաշվի անվան դաշտ | Հաշվի ճշգրիտ շարահյուսությունը, որն ընդունում է օպերատորը |
| Դոմեն դաշտով հավատարմագրերի API | Արդյո՞ք դոմենը և օգտանունը պետք է տրվեն առանձին |
| Հավատարմագրերի բաղադրիչները URI-ի ներսում | Ինչպես պետք է նախատեսված արժեքները կոդավորվեն այդ տարայի համար |
Օրինակ՝ .NET-ը տրամադրում է NetworkCredential կոնստրուկտոր՝ օգտանվի, գաղտնաբառի և դոմենի առանձին արգումենտներով։ Դոմենը երկու դաշտերում անխտիր տեղադրելը ինտեգրված նույնականացման կարգավորման տեղափոխելի եղանակ չէ։
Basic նույնականացումը այլ դեպք է՝ սերվերը տրամադրված հաշվի տեքստը մեկնաբանում է իր սեփական քաղաքականությամբ։ Նույն ցանցում լինելը չի ապացուցում, որ դոմեն նախածանցը ենթադրվում է։ Ինչպես նաև դոմենով որակավորված անունն ինքնաբերաբար այլ նույնականացման արձանագրություն չէ։
URL էսքեյփը պետք է պահպանի նախատեսված հաշիվը՝ փոխելու փոխարեն։ Հակադարձ շեղը ելակետային լեզվի տողում, հակադարձ շեղը հաշվի անվան մեջ և դրա տոկոսային կոդավորումը URI-ի ներսում առանձին շերտեր են։
Օպերատորից ստացե՛ք ընդունված ինքնության ձևը և սխեման, ապա օգտագործե՛ք համապատասխան հավատարմագրերի ինտերֆեյսը։ Կարճ անվան, դոմեն անվան և էլփոստի նման անվան միջև պատահական փոխարինումը սկզբնական 407-ի վերաբերյալ թույլ ապացույց է ստեղծում։