openlang

Rego의 allow 규칙에 기본값 false를 둬야 할까요?

{"approved": false}와 {}는 allow if input.approved == true에서 같은 답을 받습니다. 그 답은 false가 아니라 undefined입니다.

호스트는 선택적 불리언 필드 approved가 있는 객체를 받고, 쿼리가 true를 반환할 때만 작업을 허용합니다. 이 규칙은 완전 규칙이고 기본값이 없습니다. 두 입력 모두 규칙을 성립시키지 못하므로 allow는 둘 다 undefined입니다. 명시적인 false 결과는 이와 다른 결과이고, 호스트는 자신이 어느 쪽을 받았는지 알아야 합니다.

길은 두 가지입니다. default allow := false를 추가하면 두 입력 모두 false를 반환합니다. 아니면 undefined를 유지하고 호스트가 명시적으로 처리하게 합니다. 어느 쪽이든 결과가 없을 때 그것이 무슨 뜻인지는 호스트가 정합니다. 양쪽 다 근거가 있어서 아직 하나를 고르지 못했습니다.

어느 방법도 입력 문서가 존재하는지, approved가 실제로 불리언인지는 확인하지 않습니다. 그것은 입력 검증의 일이고, 쿼리 전에 이루어집니다.

이어지는 대화 2

서로의 근거를 따라
  1. 고유 링크

    검증이 쿼리보다 먼저 실행된다는 전제라면 저는 default allow := false 쪽을 택하겠습니다. 그러면 호스트에서 시험할 경우는 다섯 가지이고, 순서는 이렇습니다. 명시적 true는 허용합니다. 명시적 false는 거부합니다. 빈 객체는 거부합니다. 문서가 없으면 검증에서 실패하고 쿼리까지 가지 않습니다. approved가 불리언이 아니어도 같은 방식으로 검증에서 실패합니다.

    두 거부는 결과가 같아도 입력은 다릅니다. SQL의 WHERE도 unknown을 false와 똑같이 걸러 내고, 나중에는 어느 행이 어느 쪽이었는지 아무도 모릅니다. 진단에서 어느 거부였는지 알아야 한다면, 기본값이 채워진 allow에서 거꾸로 읽어 내려 하지 말고 그 시점에 검증 분류를 기록하십시오.

  2. 고유 링크

    false 기본값에 동의하고, 이유는 SQL이 보여 줍니다. CHECK 제약은 식이 참이거나 NULL이면 통과합니다. WHERE 절은 조건이 참인 행만 남깁니다. 같은 unknown이 규칙이 쓰인 자리에 따라 정반대 결과를 냅니다. 그래서 CHECK (approved = true)는 approved가 NULL인 행을 아무 불평 없이 받아들입니다. undefined를 CHECK가 NULL을 다루듯 다루는 호스트라면 빈 객체를 통과시킵니다. 기본값을 두면 규칙이 어디서 평가되든 결과가 같아집니다.

같은 질문의 다른 갈래

  1. 컴파일러가 부호 있는 오버플로 검사를 왜 지웠을까요?

    부호 있는 int에 대한 if (x + 1 < x)는 오버플로 방어가 아니다. C에서 부호 있는 정수 오버플로는 정의되지 않은 동작이므로, 컴파일러는 x + 1이 절대 넘치지 않는다고 가정하고 조건을 거짓으로 결론 내린 뒤…

    답글 1c