クイズ: HTTPとリソースの認可

인증된 다른 조직의 admin이 주문을 읽으려 할 때 먼저 적용할 규칙은?

• admin이므로 모든 조직 주문을 허용
• 조직 경계가 다르므로 역할과 무관하게 거부
• 소유자 이름이 같으면 조직을 무시
• 응답 본문만 비우고 상태는 200

라우팅과 상태 코드 계약까지 검증하는 테스트 방식은?

• create_order 함수를 직접 호출하고 딕셔너리만 비교
• 라우트 이름이 소스에 있는지 정규식으로 검색
• 서버를 임의 포트에 기동하고 실제 HTTP 요청을 전송
• 모든 네트워크 호출을 정적 모킹으로 교체

같은 조직 writer가 다른 사용자의 주문을 취소하려 할 때 필요한 판단은?

• writer 역할이 있으므로 항상 허용
• owner_id가 다르므로 리소스 관계에 따라 거부
• 같은 조직이면 인증 없이도 허용
• 취소 뒤 감사 로그에서 사후 탐지

인증 헤더가 아예 없는 요청과, 신원은 확인됐지만 남의 주문을 건드리는 요청의 상태 코드는?

• 둘 다 401 로 통일한다
• 둘 다 403 으로 통일한다
• 앞이 403 이고 뒤가 401 이다
• 앞이 401 이고 뒤가 403 이다

소유권 검사를 애플리케이션 조건문뿐 아니라 데이터베이스 조회 조건에도 넣는 이유는?

• 조회 범위와 권한 판단이 어긋나 남의 행이 먼저 읽히는 일을 막는다
• 질의 실행 계획이 항상 인덱스를 타게 된다
• 애플리케이션에서 권한 판단 코드를 지울 수 있다
• 조회 결과가 캐시에 더 오래 남는다

모듈을 import 하는 것만으로 출력이 생기면 무엇이 문제인가?

• 모듈이 커져 기동 시간이 길어진다
• 테스트 프레임워크가 모듈을 찾지 못한다
• 그 모듈을 부르는 모든 도구의 로그로 환경값과 비밀이 흘러간다
• 파이썬이 순환 import 를 감지하지 못한다