프록시 자격 증명의 도메인 한정 사용자 이름
불투명한 계정 이름과 도메인 필드를 따로 두는 API를 구분하고, URL 구문을 맞추기 위해서만 계정 신원을 바꾸지 마십시오.
한 답변은 DOMAIN\ 를 제거하라고 하고, 다른 답변은 추가하라고 합니다. 두 변경 모두 사용자의 프록시에는 틀릴 수 있습니다.
질문은 두 가지입니다. 서비스가 어떤 신원을 기대하는지, 그리고 선택한 API가 그 신원을 어떻게 표현하는지입니다.
| 인터페이스 | 확인해야 할 것 |
|---|---|
| 단일 계정 이름 필드 | 운영자가 허용하는 정확한 계정 구문 |
| 도메인 필드가 있는 자격 증명 API | 도메인과 사용자 이름을 따로 제공해야 하는지 |
| URI 내부의 자격 증명 구성 요소 | 의도한 값을 해당 컨테이너에 맞게 어떻게 인코딩해야 하는지 |
예를 들어 .NET은 사용자 이름, 암호, 도메인을 별도 인수로 받는 NetworkCredential 생성자를 제공합니다. 도메인을 구분 없이 두 필드에 넣는 것은 통합 인증을 구성하는 이식 가능한 방법이 아닙니다.
Basic 인증은 다른 사례입니다. 서버는 제공된 계정 텍스트를 자체 정책에 따라 해석합니다. 같은 네트워크에 있다는 사실이 도메인 접두사가 암묵적으로 붙는다는 증거는 아닙니다. 또한 도메인 한정 이름이 자동으로 다른 인증 프로토콜이 되는 것도 아닙니다.
URL 이스케이프는 의도한 계정을 보존해야 합니다. 원본 언어 문자열의 역슬래시, 계정 이름의 역슬래시, 그리고 URI 내부에서의 퍼센트 인코딩 표현은 서로 다른 계층입니다.
운영자로부터 허용되는 신원 형식과 스킴을 확인한 뒤 해당 자격 증명 인터페이스를 사용하십시오. 짧은 이름, 도메인 이름, 전자 메일처럼 보이는 이름을 무작위로 오가는 것은 원래의 407에 대해 빈약한 증거만 남깁니다.