권한 요청하기

커뮤니티 그룹 보고서 초안,

이 버전:
https://jyasskin.github.io/permissions-request
이슈 추적:
GitHub
명세 내 인라인
편집자:
(Google Inc.)
전 편집자:
(Google Inc.)
테스트:
web-platform-tests permissions-request/ (진행 중인 작업)
폴리필:
chromium/permissions.request

초록

이 명세는 강력한 기능을 사용할 권한을 요청하기 위한 균일한 함수를 제공하도록 Permissions API를 확장한다.

이 문서의 상태

이 명세는 웹 플랫폼 인큐베이터 커뮤니티 그룹에서 게시했다. 이는 W3C 표준이 아니며 W3C 표준 트랙에 있는 것도 아니다. W3C 커뮤니티 기여자 라이선스 계약(CLA)에 따라 제한적인 옵트아웃 및 기타 조건이 적용된다는 점에 유의하라. W3C 커뮤니티 및 비즈니스 그룹에 대해 더 알아보기.

1. 소개

이 문서는 웹 플랫폼에서 강력한 기능을 사용할 권한을 요청하기 위한 함수를 명시한다.

각 Web API에는 개발자가 이를 사용하려는 의도를 신호하는 서로 다른 방식이 있다:

모든 강력한 기능에 대해 따를 단일 패턴이 있다면 개발자가 권한 관련 코드를 설계하기가 더 쉽다.

2. 요청 API

partial interface Permissions {
  Promise<PermissionStatus> request(object permissionDesc);
};

request(permissionDesc) 메서드가 호출되면, 사용자 에이전트는 permissionDesc 매개변수를 전달하여 다음 알고리즘을 MUST 실행해야 한다:

  1. rootDescpermissionDesc가 참조하는 객체를 PermissionDescriptor 타입의 IDL 값으로 변환한 것으로 둔다. 이것이 예외를 던지면, 해당 예외로 거부된 promise를 반환하고 이 단계를 중단한다.

  2. typedDescriptorpermissionDesc가 참조하는 객체를 rootDesc.name권한 서술자 타입IDL 값으로 변환한 것으로 둔다. 이것이 예외를 던지면, 해당 예외로 거부된 promise를 반환하고 이 단계를 중단한다.

  3. promise를 새로 생성된 Promise로 둔다.

  4. promise를 반환하고 다음 단계를 비동기적으로 계속한다.

  5. typedDescriptor에 대해 PermissionStatus를 생성하는 단계를 실행하고, status를 그 결과로 둔다.

  6. typedDescriptor.name으로 명명된 기능의 권한 요청 알고리즘typedDescriptorstatus를 인자로 사용하여 실행한다.

  7. 이전 단계가 예외를 던졌다면, 해당 예외로 promise거부한다.

  8. 그렇지 않으면 promisestatus로 이행한다.

3. 권한 레지스트리의 추가 필드

권한 레지스트리의 강력한 기능은 추가로 권한 요청 알고리즘을 정의한다:

입력
동작

더 많은 권한 요청하기의 알고리즘을 사용하여 권한을 증가시키기 위해 필요한 프롬프트를 사용자에게 표시하고, 권한 결과 타입의 인스턴스를 그에 맞게 업데이트한다.

반환

아무것도 반환하지 않지만, 요청이 예외적으로 실패할 수 있는 경우 예외를 던질 수 있다. (단순히 권한이 거부되는 것은 예외적이지 않다.)

호출자 예
기본값

명시되지 않으면 이는 기본 권한 요청 알고리즘으로 기본 설정된다.

3.1. 기본 요청 알고리즘

기본 권한 요청 알고리즘PermissionDescriptor permissionDescPermissionStatus status가 주어졌을 때 다음 단계를 실행한다:

  1. permissionDescstatus에 대해 기본 권한 질의 알고리즘을 실행한다.

  2. status.state"prompt"가 아니면, 이 단계를 중단한다.

  3. permissionDesc를 사용할 권한을 요청한다.

  4. permissionDescstatus에 대해 기본 권한 질의 알고리즘을 다시 실행한다.

    환경 설정 객체 내에서 권한을 영구적으로 저장하지 않는 브라우저에서는, 이것이 항상 "prompt"를 반환하지만, 그래도 사용자에게 불필요한 프롬프트를 표시한다. 이는 어떤 권한도 기본 권한 요청 알고리즘을 사용해서는 안 된다는 의미일 수 있다. 이 알고리즘은 적절한 객체-능력을 결코 반환할 수 없기 때문이다.

4. 보안 고려 사항

확인된 보안 고려 사항은 없다.

5. 프라이버시 고려 사항

확인된 프라이버시 고려 사항은 없다.

적합성

문서 규약

적합성 요구 사항은 서술적 주장과 RFC 2119 용어의 조합으로 표현된다. 이 문서의 규범적 부분에서 핵심어 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”은 RFC 2119에 설명된 대로 해석되어야 한다. 그러나 가독성을 위해, 이 명세에서는 이 단어들이 모두 대문자로 나타나지 않는다.

이 명세의 모든 텍스트는 명시적으로 비규범적으로 표시된 섹션, 예제 및 참고를 제외하고는 규범적이다. [RFC2119]

이 명세의 예제는 “for example”이라는 단어로 도입되거나 규범적 텍스트와 구분되어 class="example"으로 표시된다. 다음과 같다:

이것은 정보성 예제의 예이다.

정보성 참고는 “Note”라는 단어로 시작하며 규범적 텍스트와 구분되어 class="note"로 표시된다. 다음과 같다:

Note, 이것은 정보성 참고이다.

적합한 알고리즘

알고리즘의 일부로 명령형으로 표현된 요구 사항 (예: "strip any leading space characters" 또는 "return false and abort these steps")은 그 알고리즘을 도입할 때 사용된 핵심어 ("must", "should", "may" 등)의 의미로 해석되어야 한다.

알고리즘 또는 특정 단계로 표현된 적합성 요구 사항은 최종 결과가 동등한 한 어떤 방식으로든 구현될 수 있다. 특히 이 명세에서 정의한 알고리즘은 이해하기 쉽게 하려는 의도로 작성되었으며, 성능을 고려한 것은 아니다. 구현자는 최적화할 것을 권장한다.

색인

이 명세에서 정의하는 용어

참조로 정의된 용어

참고문헌

규범적 참고문헌

[HTML]
Anne van Kesteren; et al. HTML 표준. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions. 2022년 3월 11일. WD. URL: https://www.w3.org/TR/permissions/
[RFC2119]
S. Bradner. RFC에서 요구 수준을 나타내는 데 사용하는 핵심어. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL 표준. Living Standard. URL: https://webidl.spec.whatwg.org/

정보성 참고문헌

[geolocation-API]
Andrei Popescu. Geolocation API 명세 제2 판. 2016년 11월 8일. REC. URL: https://www.w3.org/TR/geolocation-API/
[NOTIFICATIONS]
Anne van Kesteren. Notifications API 표준. Living Standard. URL: https://notifications.spec.whatwg.org/

IDL 색인

partial interface Permissions {
  Promise<PermissionStatus> request(object permissionDesc);
};

이슈 색인

환경 설정 객체 내에서 권한을 영구적으로 저장하지 않는 브라우저에서는, 이것이 항상 "prompt"를 반환하지만, 그래도 사용자에게 불필요한 프롬프트를 표시한다. 이는 어떤 권한도 기본 권한 요청 알고리즘을 사용해서는 안 된다는 의미일 수 있다. 이 알고리즘은 적절한 객체-능력을 결코 반환할 수 없기 때문이다.