인증 코드 리뷰 가이드라인

인증 코드 리뷰 가이드라인에 대해 설명합니다.

이 페이지는 정책 변경, 권한 정의 및 인증 로직과 관련된 머지 요청을 리뷰를 위해 준비하는 방법에 대한 Govern:Authorization 팀 의 지침을 제공합니다. 파일 구성 # 동일한 조건에 대한 모든 권한은 하나의 .policy 블록에 있어야 하며, 파일 전체에 분산되어서는 안 됩니다. 이렇게 하면 파일을 검색하지 않고도 역할이나 조건이 부여하는 전체 권한 집합을 쉽게 볼 수 있습니다. # 나쁜 예 - 조건과 규칙이 섞이고 역할별로 규칙이 분산됨 rule { guest }.enable :read_issue rule { guest }.enable :read_project # 좋은 예 - 먼저 모든 조건, 그런 다음 역할별로 그룹화된 규칙 rule { guest }.policy do enable :read_issue enable :read_project end 안티패턴 # 기본 정책에서 권한을 활성화하지 마십시오 # BasePolicy 는 모든 다른 정책에 의해 상속되므로, 여기서 활성화된 모든 권한은 시스템의 모든 개체에서 암묵적으로 사용 가능합니다. 권한이 어떤 리소스에 대해 인증되는지에 대한 제약이 없으므로 이는 모호성과 보안 위험을 만듭니다. 동적 권한 정의 피하기 # 동적으로 정의된 권한은 코드베이스에서 추적하기 어렵습니다. 명시적으로 선언되지 않고 런타임에 생성된 권한은 권한 이름 검색 시 결과가 없어 이름 변경이나 제거가 완료되었는지 확인이 불가능합니다. # 나쁜 예 - 권한 이름이 동적으로 구성되어 검색할 수 없으며, # 실제로 어디에서도 사용되지 않는 권한을 활성화/방지할 수 있습니다. readonly_features.each do | feature | prevent : "create_ #{feature} " prevent : "update_ #{feature} " prevent : "admin_ #{feature} " end # 좋은 예 - 각 방지가 명시적으로 선언됨 rule { read_only }.policy do prevent :create_issue prevent :update_issue prevent :admin_issue # ... 권한당 한 줄 end 조건에서 잘못된 :scope 사용 피하기 # 모든 condition 은 캐시됩니다. :scope 옵션은 DeclarativePolicy에 캐시 키가 무엇인지 알려줍니다 — 잘못 설정하면 캐시된 결과가 너무 광범위하게 공유되어 한 사용자의 결과가 다른 컨텍스트로 유출되는 버그가 발생합니다. 규칙은 다음과 같습니다: scope: :user 는 조건이 사용자 데이터만 읽는 경우에만 사용 — 주제 데이터 없음. scope: :subject 는 조건이 주제 데이터만 읽는 경우에만 사용 — 사용자 데이터 없음. scope: :global 은 조건이 사용자나 주제 데이터가 필요 없는 경우에만 사용. 조건이 사용자와 주제 데이터 모두 를 읽는 경우 :scope 를 생략(기본값). 참조: DeclarativePolicy 캐시 공유 범위 # 나쁜 예 - scope: :u