권한 부여

어디에서 권한을 확인해아 하는가?

권한을 확인하는 위치를 결정할 때에는 여러 계층에서 다중 확인을 실시하여 방어력을 확실히 하는 것이 좋습니다. 낮은 수준의 계층부터 시작하여 finders 및 services와 같은 낮은 수준의 계층부터 시작하여 GraphQL, 공개 REST API, 컨트롤러와 같은 고수준의 계층까지 여러 번 확인합니다.

자세한 내용은 추상화 재사용 가이드라인을 참조하세요.

동일한 리소스를 여러 곳에서 보호하는 것은 한 계층이 침해당하거나 누락되더라도 고객 데이터가 추가 계층에 의해 여전히 보호된다는 것을 의미합니다.

권한에 대한 자세한 내용은 보안 코딩 가이드라인의 권한 부분을 참조하세요.

고려 사항

서비스 또는 finders는 적절한 위치입니다. 왜냐하면:

  • 여러 엔드포인트가 서비스 또는 finders를 공유하므로 하류 로직이 재사용될 가능성이 더 높습니다.
  • 때로는 권한 부여 로직을 레코드를 필터링하기 위한 DB 쿼리에 통합해야 할 수도 있습니다.
  • 디스플레이 레이어에서는 UX를 개선하기 위해 권한 확인을 제공하기 위해 사용해야 하며, 보안 확인으로 사용해서는 안 됩니다. 예를 들어, 버튼과 같은 비데이터 요소를 표시하고 숨기는 데 사용합니다.

다중 방어의 단점은 다음과 같습니다:

  • DeclarativePolicy 규칙은 비교적 성능이 우수하지만 조건은 데이터베이스 호출을 수행할 수 있습니다.
  • 높은 유지 관리 비용.

예외

개발자는 특정 사례에 대한 위험과 단점을 고려한 후 권한 부여를 하나의 영역에서만 수행할 수 있습니다.

예외를 만들 때 도메인 논리(서비스 또는 finders)를 우선으로 하세요.

백엔드 워커 논리와 같은 로직은 현재 사용자를 기준으로 권한을 부여할 필요가 없을 수 있습니다. 서비스 또는 finders의 생성자가 current_user를 기대하지 않는 경우에는 일반적으로 권한을 확인하지 않습니다.

프론트엔드

UI 요소에서 능력 확인을 하는 경우, 사용자가 적절한 액세스 권한이 있는지 확인하도록 함으로써 해당 기능을 사용할 수 없게 만드는 것을 확실히 해야 합니다.

UI 요소가 HAML 인 경우 Ability.allowed?(user, action, subject)를 확인하기 위해 내장된 루비를 사용할 수 있습니다.

UI 요소가 JavaScript 또는 Vue인 경우, ApplicationController를 상속하는 모든 컨트롤러에서 사용 가능한 push_frontend_ability 메서드를 사용하세요. 예를 들어 다음과 같이 사용할 수 있습니다: 

before_action do
  push_frontend_ability(ability: :read_project, resource: @project, user: current_user)
end

그런 다음 JavaScript에서 능력의 상태를 다음과 같이 확인할 수 있습니다: 

if ( gon.abilities.readProject ) {
  // ...
}

JavaScript에서 능력의 이름은 항상 camelCase이므로 gon.abilities.read_project를 확인하는 것은 작동하지 않습니다.

Vue 템플릿에서 능력을 확인하려면 Vue에서 능력에 대한 개발자 문서를 참조하세요.

팁

클래스가 current_user를 허용하는 경우 권한을 부여할 책임이 있을 수 있습니다.

예제: 새 API 엔드포인트 추가

기본적으로 우리는 엔드포인트에서 권한을 부여합니다. 기존 능력을 확인하는 것이 합리적일 경우도 있습니다. 그렇지 않은 경우 새로운 능력을 추가해야 합니다.

부가적으로 대부분의 엔드포인트는 리소스에 대한 CRUD(생성, 읽기, 업데이트, 삭제) 액션으로 깔끔하게 분류할 수 있습니다. 서비스 및 능력도 이와 일치하므로 많은 경우 Projects::CreateService 또는 :read_project와 같은 이름으로 지정됩니다.

예를 들어 전체 엔드포인트를 서비스로 추출하는 경우, can? 확인은 이제 서비스에서 이루어집니다. 우리의 목적을 위해 기존 finder를 수정하고 있는 경우, finder가 능력을 확인해야 하는지 확인해야 합니다.

  • Finder가 current_user를 허용하지 않고 따라서 권한을 확인하지 않는 경우, 아마도 아니요.
  • Finder가 current_user를 허용하고 권한을 확인하지 않는 경우에는 finder의 다른 사용법을 재확인해야 하며 권한을 추가하는 것을 고려해야 합니다.
  • Finder가 current_user를 허용하고 이미 권한을 확인하는 경우, 우리는 우리의 경우를 추가해야 하거나 기존의 확인이 적절한지 확인해야 합니다.