Прокси нэвтрэх мэдээлэл дэх доменоор тодорхойлогдсон хэрэглэгчийн нэр
Тодорхой бус бүртгэлийн нэрийг тусдаа домэйн талбартай API-аас ялгаж, зөвхөн URL-ын синтаксийг хангахын тулд бүртгэлийн таних тэмдгийг өөрчлөхөөс зайлсхий.
Нэг хариулт DOMAIN\-г хасах хэрэгтэй гэж хэлдэг. Нөгөө нь нэмэх хэрэгтэй гэдэг. Хоёр өөрчлөлт таны проксид буруу байж болно.
Хоёр асуулт байна: үйлчилгээ ямар таних тэмдэг хүлээж байгаа, сонгосон API тэр таних тэмдгийг хэрхэн төлөөлж байгаа.
| Интерфэйс | Юуг тогтоох |
|---|---|
| Ганц бүртгэлийн нэрний талбар | Операторын хүлээн авдаг бүртгэлийн яг синтакс |
| Домэйн талбартай нэвтрэх мэдээллийн API | Домэйн ба хэрэглэгчийн нэрийг тусдаа өгөх эсэх |
| URI доторх нэвтрэх мэдээллийн бүрэлдэхүүн хэсэг | Зорьсон утгуудыг тухайн саванд хэрхэн кодлох |
Жишээлбэл, .NET нь хэрэглэгчийн нэр, нууц үг, домэйн тусдаа аргументтай NetworkCredential байгуулагчийг санал болгодог. Домэйныг ялгаваргүй хоёр талбарт хийх нь нэгдсэн баталгаажуулалтыг тохируулах зөөврийн арга биш.
Basic баталгаажуулалт өөр тохиолдол: сервер өгөгдсөн бүртгэлийн текстийг өөрийн бодлогоор тайлбарладаг. Нэг сүлжээнд байх нь домэйны угтвар далд гэдгийг нотолохгүй. Мөн доменоор тодорхойлогдсон нэр автоматаар өөр баталгаажуулалтын протокол болдоггүй.
URL экранизаци нь зорьсон бүртгэлийг хадгалах ёстой, өөрчлөх биш. Эх хэлний мөрөн дэх ташуу зураас, бүртгэлийн нэрэн дэх ташуу зурмаас ба URI доторх түүний хувийн кодчилол нь тусдаа давхаргууд.
Оператороос хүлээн авах таних тэмдгийн хэлбэр ба схемийг аваад, дараа нь тохирох нэвтрэх мэдээллийн интерфэйсийг ашигла. Богино нэр, домэйн нэр, имэйлтэй төстэй нэр хооронд санамсаргүй солих нь анхны 407-ын талаар сул нотолгоо үүсгэдэг.