Proksi hisob ma'lumotlarida domen bilan belgilangan foydalanuvchi nomlari
Shaffof bo'lmagan hisob nomini alohida domen maydonlari bo'lgan API'lardan ajratib turing va faqat URL sintaksisini qondirish uchun hisob shaxsini o'zgartirishdan saqlaning.
Bir javob DOMAIN\ ni olib tashlang deydi. Boshqasi uni qo'shing deydi. Ikkala o'zgartirish ham proksingiz uchun noto'g'ri bo'lishi mumkin.
Ikkita savol bor: xizmat qaysi shaxsni kutadi va tanlangan API bu shaxsni qanday ifodalaydi.
| Interfeys | Nimani aniqlash kerak |
|---|---|
| Bitta hisob nomi maydoni | Operator qabul qiladigan aniq hisob sintaksisi |
| Domen maydoni bo'lgan hisob ma'lumotlari API'si | Domen va foydalanuvchi nomi alohida berilishi kerakmi |
| URI ichidagi hisob ma'lumotlari komponentlari | Ko'zlangan qiymatlar o'sha idish uchun qanday kodlanishi kerak |
Masalan, .NET foydalanuvchi nomi, parol va domen uchun alohida argumentlarga ega NetworkCredential konstruktorini taqdim etadi. Domenni farqlamasdan ikkita maydonga joylashtirish integratsiyalashgan autentifikatsiyani sozlashning ko'chma usuli emas.
Basic autentifikatsiya boshqa holat: server berilgan hisob matnini o'z siyosati bo'yicha talqin qiladi. Bir tarmoqda bo'lish domen prefiksi nazarda tutilganini isbotlamaydi. Shuningdek, domen bilan belgilangan nom avtomatik ravishda boshqa autentifikatsiya protokoli emas.
URL ekranlashtirish ko'zlangan hisobni saqlashi kerak, uni o'zgartirmasligi kerak. Manba tili satridagi teskari chiziq, hisob nomidagi teskari chiziq va uning URI ichidagi foizli kodlanishi alohida qatlamlardir.
Operatordan qabul qilingan shaxs shakli va sxemasini oling, so'ng tegishli hisob ma'lumotlari interfeysidan foydalaning. Qisqa nom, domen nomi va elektron pochtaga o'xshash nom o'rtasida tasodifiy almashish asl 407 haqida zaif dalil yaratadi.