브라우저 확장은 요청을 전달하는 프록시와 대상 웹사이트라는 두 곳에서 인증 챌린지를 만날 수 있습니다. 둘이 자동으로 같은 계정을 받아서는 안 됩니다.

Chrome의 webRequest.onAuthRequired 이벤트에서 유용한 구분자는 isProxy입니다. 프롬프트를 없애기 위해 그 확인만 제거하는 콜백은 프록시 자격 증명을 오리진 챌린지에 제공하기 시작할 수 있습니다.

신뢰하려는 프록시에 맞추기

isProxy 확인은 시작일 뿐입니다. 처리를 예상된 프록시 챌린저와 요청 컨텍스트로 제한하세요. 여러 엔드포인트를 관리하는 확장은 모든 챌린지에 하나의 전역 비밀번호가 아니라 해당 엔드포인트의 계정을 선택해야 합니다.

프록시 경로를 설정하는 것과 그 로그인을 처리하는 것이 하나의 권한이나 하나의 API 호출이라고 가정하지 마세요. Chrome은 이를 별도로 문서화합니다. 이벤트 데이터와 인증 권한에는 현재 webRequest 참조를 사용하세요. Manifest V3 리스너 등록 예시는 콜백 내부의 동기 등록과 계정 선택을 보여 줍니다.

매니페스트 세대 확인

실험적 WebRequest API를 언급하는 예시는 오래된 확장 릴리스에서 나온 것입니다. 현재 권한 요구 사항은 확장의 매니페스트 세대와 배포 모델에 따라 달라집니다. 특히 인증 처리는 자체 지원 권한 경로가 있습니다. 구식 차단 리스너 예시만으로는 Manifest V3 확장이 이를 변경 없이 실행할 수 있음을 입증하기에 충분하지 않습니다.

올바른 핸들러는 거부된 동일한 자격 증명을 무한정 다시 시도하는 것도 피해야 합니다. 계정을 제공한 뒤의 두 번째 챌린지는 비밀번호를 영원히 재생하라는 요청이 아니라 조사할 증거로 다루세요.

자격 증명은 확장의 적절한 보호 처리 경로에 남아 있어야 합니다. PAC 파일에 게시하거나 배포용 샘플에 하드코딩하지 마세요. 목표는 범위가 좁은 프록시 로그인이지, 모든 인증 챌린지에 같은 비밀으로 응답하는 브라우저 전체 규칙이 아닙니다.

관련 글