Implement Authorization using Row Level Security (RLS) with Supabase (Step By Step Guide)

🔐 행 수준 정책 (Row Level Security)

1. 🛡️ 행 수준 보안이란? RLS

• 클라이언트가 데이터베이스와 직접 통신 가능
• 인증 토큰을 통해 사용자 인증
• 데이터베이스가 행 수준 정책에 따라 접근 권한 결정
• API를 거치지 않아 쿼리 효율성 향상 가능
• API의 잘못된 논리로 인한 데이터 유출 방지

2. 📝 블로그 프로젝트 예시

2.1. 테이블 구조

• ==posts==: ID, 제목, 내용, 사용자 ID, 타임스탬프, 게시 여부
• ==comments==: ID, 내용, 사용자 ID, 타임스탬프, 관련 게시물 ID (posts.ID)

2.2. 애플리케이션 시나리오

1. ==사용자 등록==: Ash와 Gary가 각각 pokemon.com 도메인으로 가입
2. ==게시물 작성==:
   • Ash가 새 게시물 작성 (미게시 상태)
   • Ash는 자신의 미게시 게시물 확인 및 편집 가능
3. ==문제점==: Gary도 Ash의 미게시 게시물을 볼 수 있음

3. ⚙️ 행 수준 보안 활성화 및 정책 설정

3.1. RLS 활성화

• Supabase 대시보드에서 ==posts 테이블에 대해 RLS 활성화==
• ==결과==: 모든 접근이 차단됨 (삽입, 선택, 업데이트, 삭제)

3.2. 정책 생성: 사용자 ID 기반 접근 허용

• 템플릿 활용: "사용자 ID를 기반으로 사용자에 대한 삭제 액세스 활성화"
• 정책 수정: 선택, 삽입, 업데이트, 삭제 모두 허용
• 조건 설정: ==user_id = auth.uid() (현재 로그인한 사용자와 게시물 작성자가 동일한 경우)==

3.3. 정책 동작 원리

• ==**auth.uid()**==: 현재 로그인한 사용자 ID 반환 (Supabase 제공)
• WHERE 절과 유사하게 동작하여 조건에 맞는 행만 선택
• JavaScript의 ==filter() 함수와 유사==

3.4. 정책 검토 및 저장

• SQL 편집기를 통해 수동으로 SQL 쿼리 실행 가능 (동일한 동작 확인)

4. 🚦 게시 상태에 따른 접근 제어

4.1. 문제점

• Ash가 게시물을 게시해도 Gary는 계속 접근 가능

4.2. 정책 추가: 게시된 게시물 접근 허용

• 새로운 정책 생성: "사용자가 게시된 게시물을 선택할 수 있도록 허용"
• 조건 설정: ==published = true==

4.3. 동작 확인

• Gary가 게시된 게시물을 볼 수 있게 됨
• Ash가 게시물을 미게시로 변경하면 Gary는 더 이상 해당 게시물을 볼 수 없음

5. 🚫 예상치 못한 접근 시도 방어

5.1. 문제점

• URL을 직접 입력하면 게시되지 않은 게시물에 접근 가능
• 게시물 작성자가 아닌 사용자가 게시물을 삭제 시도 가능

5.2. 행 수준 보안의 장점

• 애플리케이션 코드의 허점을 이용한 악의적인 시도 방어
• 데이터베이스 레벨에서 접근 제어를 수행하므로 안전성 확보

6. 💬 댓글 기능 구현 및 보안 설정

6.1. 초기 상태

• RLS가 비활성화된 상태에서 댓글 작성 및 조회 가능
• RLS 활성화 후에는 모든 댓글 접근 차단

6.2. 정책 생성: 게시물 접근 권한 기반 댓글 접근 권한 부여

• 새로운 정책 생성: "사용자가 볼 수 있는 게시물에 대한 댓글을 볼 수 있도록 허용"
• 조건 설정: 게시물 테이블에서 현재 댓글이 속한 게시물을 조회하여 접근 권한 확인

EXISTS (
  SELECT 1
  FROM posts
  WHERE posts.id = comments.post_id
  AND [기존 게시물 접근 정책 조건]
)

6.3. 정책 추가: 댓글 삽입 권한 제어

• 새로운 정책 생성: "사용자가 자신이 작성한 댓글만 삽입할 수 있도록 허용"
• 조건 설정: ==auth.uid() = comments.user_id==

6.4. 정책 추가: 댓글 수정 및 삭제 권한 제어

• 삽입 정책과 동일한 조건 사용

6.5. 정책 추가: 게시물 소유자가 댓글 관리 권한 부여

• 새로운 정책 생성: "사용자가 자신의 게시물에 있는 댓글을 관리할 수 있도록 허용"
• 조건 설정: 현재 사용자가 댓글의 게시물을 소유하고 있는지 확인

EXISTS (
  SELECT 1
  FROM posts
  WHERE posts.id = comments.post_id
  AND posts.user_id = auth.uid()
)

7. ✅ 최종 결과

• 완벽하게 작동하는 블로그 완성
• 미게시 게시물은 작성자만 볼 수 있음
• 게시된 게시물은 모든 사용자가 읽을 수 있음
• 댓글 작성 및 관리는 적절한 권한을 가진 사용자만 가능

8. 🔗 추가 정보

• Supabase 인증 문서 링크 (설명 참조)
• Supabase YouTube 채널
• Supabase Twitter
• Supabase Discord

대본

[음악] 안녕하세요 Supabase의 Jon입니다. 이 비디오에서 우리는 행 수준 정책에 대해 모두 배울 것입니다. 이것은 특히 SQL을 처음 사용 하거나 인증 규칙을 작성하는 경우 많은 사람들을 당황하게 만드는 개념입니다. 이 계층에서는 보이는 것만큼 무섭지 않을 것이라고 약속합니다. 따라서 대부분의 사람들 이 클라이언트, API 및 데이터베이스가 있고 클라이언트가 직접만 수행할 수 있는 이러한 종류의 3부분 아키텍처의 정신 모델을 어떻게 가지고 있는지 알아보겠습니다. API와 통신 하고 API는 데이터베이스와 직접 통신할 수 있는 유일한 것이므로 클라이언트가 데이터베이스에 있는 레코드를 원하면 API로 가서 이것이 내가 누구인지 말해야 합니다. API는 내가 당신을 믿느냐 안 믿느냐를 결정하고 만약 그렇다면 그들은 데이터베이스에 대한 특수 키를 가진 유일한 사람이므로 데이터베이스로 가서 그 기록을 가져온 다음 클라이언트에게 다시 보냅니다. 이제 행 수준 보안 아키텍처에서 클라이언트는 데이터베이스와 직접 통신할 수 있으므로 중간에 해당 API를 실제로 가질 필요가 없습니다. 클라이언트는 인증 토큰을 통해 보내거나 데이터베이스에 자신이 누구인지 말한 다음 데이터베이스가 기반으로 결정합니다. 해당 행 수준 정책에서 사용자가 이 데이터에 액세스할 수 있거나 그렇지 않은 경우 해당 결과를 클라이언트에 직접 보낼 수 있으므로 쿼리가 조금 더 효율적일 수 있습니다 . API를 통해 추가 홉을 수행하지만 데이터베이스 자체 의 데이터에 대한 액세스 규칙을 작성하여 데이터베이스의 일부 데이터를 잠재적으로 노출시키는 잘못된 논리를 API에 작성하지 않도록 보호할 수 있습니다 . 이는 실수로 유출되는 것을 매우 어렵게 만듭니다. 해당 데이터에 액세스할 수 있는 사람만 액세스할 수 있으므로 여기에서 자체 애플리케이션에서 행 수준 정책을 구현하는 방법을 살펴보겠습니다. Supabase에 구축 중인 블로그 프로젝트가 있는데 두 개의 테이블이 있으므로 게시물과 댓글 각 게시물에는 ID 제목이 있습니다. 게시물의 내용 사용자 ID 이므로 이는 블로그를 작성한 사용자이며 타임스탬프에서 생성되었으며 블로그가 현재 게시되었는지 여부에 따라 댓글 테이블이 있습니다. 여기에는 ID와 콘텐츠가 있고 댓글을 작성한 사용자와 타임스탬프가 있고 그와 관련된 게시물이 있으므로 각 게시물에 많은 댓글이 있고 모든 댓글이 게시물에 속하는 매우 일반적인 일대다 관계를 모델링합니다. 그럼 그것을 사용하고 있는 애플리케이션을 살펴보겠습니다. 여기 Supabase 애플리케이션이 있습니다. ash pokemon.com이라는 새 계정에 가입하려고 합니다. 그 사람은 여기 오른쪽에 있는 매우 안전한 비밀번호 비밀번호를 가질 수 있습니다. 두 번째 사용자를 등록 할 예정 이고 당연히 우리는 pokemon.com에서 Ash의 라이벌인 Gary를 등록할 것이고 그도 동일한 비밀번호를 갖게 될 것입니다. 왜냐하면 현재 Ash의 Violet Town에서는 보안에 그다지 신경 쓰지 않는 것 같기 때문입니다. 그는 이 게시물에 제목을 지정한 다음 그의 첫 포켓몬의 모험에 대해 쓸 수 있도록 새 게시물을 만들 예정입니다. 이제 그는 이것을 게시할 준비가 아직 되지 않았습니다. 그는 어쩌면 이 이야기에 조금 더 추가할 수 있을 것이라고 생각합니다. 저장을 클릭하고 나중에 다시 방문하면 Ash가 이제 이 게시물을 볼 수 있으므로 원하는 경우 계속 편집할 수 있습니다. 이 이야기가 세상에 말할 가치가 없다고 판단하고 모든 게시물로 돌아 가면 삭제할 수 있습니다. 게시물은 거기에 나열된 자신의 게시물을 볼 수 있는데, 이는 게시물이 게시되지 않았더라도 Ash가 계속 볼 수 있고 작업을 계속할 수 있어야 하기 때문에 문제는 여기로 와서 새로 고치는 것입니다. gary 측에서는 gary도 블로그가 아직 게시되지 않았더라도 볼 수 있으므로 행 수준 정책을 사용하여 이 문제를 해결해 보겠습니다. 그러면 Ash만이 게시되지 않은 블로그를 볼 수 있고 확실히 볼 수 있는 유일한 블로그가 될 것입니다. 편집하거나 삭제하려면 Supabase 대시보드로 돌아가서 인증, 정책으로 이동하면 기본적으로 테이블에서 rls 또는 행 수준 보안이 비활성화되어 있는 것을 볼 수 있으므로 게시 테이블과 첫 번째 테이블에 대해 이를 활성화하겠습니다. 우리가 주목하게 될 것은 애플리케이션으로 돌아가서 모든 게시물을 보려고 하면 다음과 같은 내용을 볼 수 있다는 것입니다. 심지어 Ash도 그의 게시물을 볼 수 없으며 우리가 Gary 측을 새로 고치면 그는 분명히 그것을 볼 수 없습니다. 그 이유는 기본적으로 행 수준 보안이 해당 테이블을 완전히 잠가서 삽입 선택 요청을 자동으로 거부하기 때문입니다. 해당 테이블의 행을 업데이트하거나 삭제합니다. 해당 작업을 다시 잠금 해제하는 유일한 방법은 새 정책을 생성하는 것입니다. 따라서 여기서는 템플릿에서 또는 처음부터 정책을 생성할 수 있습니다. 그렇게 하면 어떻게 되는지 보여드리겠습니다. 템플릿에서 이 맨 아래 옵션으로 내려가면 사용자 ID를 기반으로 사용자에 대한 삭제 액세스를 활성화합니다. 따라서 이는 우리가 원하는 것과 유사하게 들리지만 단순히 삭제하는 대신 모든 작업을 활성화하고 싶지만 확실히 다음을 기반으로 하길 원합니다. 현재 로그인된 사용자이므로 이 템플릿을 사용하고 싶다면 선택 삽입 업데이트 삭제 또는 전체를 선택할지 여부를 변경할 수 있습니다. 그러면 모두에 이러한 네 가지 작업이 모두 포함됩니다. 그런 다음 업데이트할 수 있습니다. 사용자 ID를 기반으로 사용자에 대한 모든 작업을 활성화한다고 말할 수 있는 이름입니다 . 여기서 실제로 생성하는 정책을 살펴보면 이는 단지 조건일 뿐이 므로 이에 대해 생각하는 좋은 방법은 일반적인 where 절과 같습니다. sql 그래서 사용자 ID 열이 현재 로그인한 사용자로 설정된 게시물의 모든 열을 선택하려는 경우 행 수준 정책에서 지정하는 것은 바로 이 where 절이므로 이 where 절은 자동으로 연결됩니다. 우리가 하려는 삽입 선택 업데이트 또는 삭제 문에 추가하므로 SQL 구문에 익숙하지 않은 경우 API 수준에서 직접 수행해야 한다는 것을 기억할 필요가 없습니다. 이는 필터 문과 유사합니다. 자바스크립트에서는 모든 게시물 목록이 있고 post.userid가 현재 로그인한 사용자 ID와 동일한 게시물을 필터링하려는 경우 여기에서 배열을 반환하므로 이는 필터링된 게시물과 같습니다. 여기에는 이 조건이 참인 게시물만 포함되므로 이것이 바로 여기 정책에서 이 조건을 사용하여 수행하는 작업입니다. 즉, 기본적으로 auth.userid라는 특수 기능이 있는 모든 결과를 필터링 하려고 합니다. 현재 로그인된 사용자를 반환 하므로 이는 Supabase에서 제공하며 해당 사용자 ID가 사용자 ID에 대한 이 테이블의 열과 동일한지 확인하고 있으므로 이 사람이 이 게시물을 작성한 사람임을 기억하세요. 현재 로그인한 사용자가 포스트 도트 사용자 ID 열과 동일하면 모두 괜찮습니다. 이는 true를 반환하고 여기에 업데이트가 포함되어 있으므로 지금 삽입하거나 업데이트하거나 삭제하는 것이 모두 좋습니다. 너비 확인을 추가하려면 여기에 동일한 조건을 복사하여 붙여넣기만 하면 됩니다. 따라서 현재 로그인한 사용자가 사용자 ID 열과 동일한지 확인하고 검토를 클릭하면 이를 확인할 수 있습니다. 마법 같은 일은 없습니다. 단지 뒤에서 SQL을 생성하는 것뿐입니다. 따라서 실제로 이 전체 SQL 문을 복사하고 SQL 편집기로 와서 수동으로 실행하면 정확히 동일한 작업을 수행하지만 우리가 하는 일은 모두 같습니다. 하는 일은 사용자 ID를 기반으로 사용자에 대한 모든 작업 활성화라는 이름의 정책을 만드는 것입니다 . 이를 public.post 테이블에 설정하고 이 조건을 실행하여 수행하려고 할 때마다 auth.uid가 사용자 ID와 동일하도록 하려고 합니다. 이러한 작업 중 하나이므로 이제 정책 저장을 클릭할 수 있습니다. 이제 애플리케이션으로 돌아가서 Ash 측을 새로 고치면 이제 해당 게시물을 볼 수 있고 해당 게시물을 클릭하여 이에 대한 추가 정보를 얻을 수 있습니다. 게시물을 편집하고 게리에게 빨리 말하고 싶다고 말하면 그는 괜찮다고 말할 수도 있습니다. 저는 이 게시물을 게시할 준비가 되었고 저장을 클릭할 준비가 되었습니다. 하지만 이제 그 게시물이 게시되었더라도 우리가 게리 쪽으로 가서 새로 고치면 됩니다. 여전히 해당 게시물을 볼 수 없습니다. 그 이유는 블로그를 작성한 사람이 볼 수 있도록 정책을 만들었지 만 아직 다른 사람이 액세스할 수 있도록 설정하지 않았기 때문입니다. 따라서 누구나 볼 수 있도록 정책을 만들어 보겠습니다. 게시된 게시물을 보려면 Supabase로 돌아가서 새 정책을 생성해 보겠습니다. 이번에는 처음부터 정책을 생성하여 사용자가 게시된 게시물을 선택할 수 있도록 하는 이 정책이 얼마나 쉬운지 확인하겠습니다. 우리는 이것을 선택에 설정하고 싶습니다 그런 다음 여기서 하고 싶은 것은 게시된 값이 true인 경우 이 게시물을 표시하고 싶으므로 해당 정책을 검토하고 저장해 보겠습니다. 이제 게리의 측면으로 돌아가서 새로 고치면 게리도 이제 해당 게시물을 볼 수 있습니다. 굉장합니다. 하지만 이제 Ash가 해당 게시물을 더 이상 게시하지 않기로 결정하면 여기로 와서 체크 표시를 해제할 수 있습니다. 게시된 다음 Gary가 새로고침하면 더 이상 해당 게시물을 볼 수 없으므로 정책은 예상대로 작동하고 있습니다. 저는 여기로 돌아와서 이 게시물을 편집하고 다시 게시합니다. 멋진 점은 제가 이 블로그 게시물을 편집하기 위해 이 URL을 복사 하고 여기에 붙여넣으면 gary가 이 페이지를 볼 수 있다는 것입니다. 왜냐하면 우리가 어떤 논리도 구현 하지 않았기 때문입니다. 이를 중지하기 위한 우리의 애플리케이션과 그가 더욱 악의적으로 행동하고 내려와서 라이벌의 게시물을 삭제하기로 결정한 경우 모든 것이 잘 된 것처럼 보이지만 오류 메시지는 나타나지 않았지만 이제 우리는 랜딩 페이지로 리디렉션되었으며 게시물이 여전히 거기에 있으므로 삭제되지 않았으며 이것이 행 수준 정책의 진정한 힘입니다. 우리는 애플리케이션에서 이 극단적인 경우를 완전히 잊어버렸지만 데이터베이스 계층에서 해당 정책을 작성했기 때문에 여전히 해당 작업을 수행할 수 없습니다. 따라서 우리가 API 계층에서 작성한 코드가 아무리 나쁘고 사람들에게 악의적인 작업을 수행하도록 얼마나 많은 권한을 부여했는지에 관계없이 데이터는 여전히 안전하며 이것이 가장 중요하므로 이것이 좋아 보이는지 살펴보겠습니다. 댓글을 활성화할 수 있으므로 게시물 중 하나를 클릭하고 Ash 쪽의 동일한 게시물에 오면 이 댓글 섹션이 있는 것을 볼 수 있으며 이제 Gary는 '잘했어요 Ash가 정말 자랑스러워요'라고 말하는 댓글을 추가할 수 있습니다. 그가 그 댓글을 추가하면 우리가 Ash 쪽에서 새로고침하면 그 댓글을 볼 수 있고 우리는 와우 고마워요 게리 좋은 사람이라고 말할 수 있습니다. 그리고 다시 게리 쪽으로 가서 새로 고치면 우리는 Ash가 보낸 매우 친절한 메시지를 볼 수 있습니다 여기에서 주석 테이블에 대한 행 수준 보안을 활성화하고 다시 여기로 돌아와서 새로 고치면 두 사용자 모두에 대해 아무 것도 볼 수 없는지 확인할 수 있습니다. 따라서 이제 이러한 주석을 다시 볼 수 있도록 정책을 작성해 보겠습니다. 어떤 종류의 댓글을 볼 수 있어야 하는지 생각해 보세요. 게시물을 볼 수 있으면 볼 수 있는 게시물과 직접 연결되어 있기 때문에 모든 댓글을 볼 수 있다는 것은 말이 되지만 실제로는 말이 되지 않습니다. 볼 수 없는 게시물에 대한 댓글을 보려면 정책 내의 다른 테이블에서 데이터를 선택하여 해당 댓글을 볼지 여부를 결정하는 방법을 살펴보겠습니다. 댓글 테이블과 다시 이 테이블을 처음부터 생성할 것입니다. 우리는 선택 항목을 살펴볼 것입니다. 이 정책은 사용자가 동일한 정책을 다시 구현하는 대신 볼 수 있는 게시물에 대한 댓글을 볼 수 있도록 해줍니다. 우리는 포스트 테이블에 여기에 약간의 트릭을 사용하여 내가 현재 선택하려고 하는 이 댓글에 대해 잘 말할 수 있습니다. 나는 그것이 어떤 포스트에 속하는지 알고 있으므로 내가 가서 해당 포스트에 대한 선택 문을 작성 하면 ' 내가 볼 수 있다는 것은 내가 이 댓글도 볼 수 있어야 한다는 뜻이므로 게시물 도트 ID가 현재 댓글 도트 포스트 ID 와 동일한 게시물에서 별표를 선택하여 그렇게 할 수 있습니다. 현재 우리가 선택하려고 하는 댓글은 그것이 속한 게시물을 살펴보고 게시물 테이블에서 해당 게시물 ID를 가진 게시물을 찾은 다음 해당 게시물을 선택할 수 있으면 반환될 것입니다. 우리는 모든 열을 고려하므로 실제로 열에 대해서는 신경 쓰지 않습니다. 실제로 거기에 있는 데이터에는 신경 쓰지 않습니다. 단지 선택할 수 있는지 여부에만 관심이 있으므로 이를 1로 바꿀 수 있습니다. 열의 값을 반환하는 대신 true를 반환하므로 이 게시물을 선택할 수 있으면 true 값만 반환할 것입니다. 즉, 이 select 문을 다른 문에 래핑하여 존재 하는지 확인할 수 있다는 뜻입니다. 이제 이 select 문이 true를 반환하면 이 정책은 true를 반환하고 해당 주석을 선택할 수 있으므로 이제 애플리케이션으로 돌아가 Ash 측에서 새로 고치면 됩니다. 우리는 그 두 개의 댓글을 봐야 하고, 게리 쪽을 새로 고치면 그 두 개의 댓글을 볼 수 있습니다. 이제 게리로서 내가 애쉬에게 감사하다고 말하고 새 댓글을 추가하려고 하면 이것이 행 수준을 위반한다는 오류가 발생하게 됩니다. 보안 정책이고 아직 삽입할 규칙을 추가하지 않았기 때문입니다. 그러면 그렇게 하고 새 정책을 만들고 다시 처음부터 생성할 수 있습니다. 이것이 삽입될 것이므로 사용자가 다음에 코멘트를 삽입할 수 있습니다. 그들이 볼 수 있는 게시물 과 이 정책은 우리의 선택 정책과 매우 유사할 것이므로 우리가 볼 수 있는 게시물에 대해서만 댓글을 삽입할 수 있기를 원 하지만 이에 대해 생각해 보면 실제로는 허용될 것입니다. 다른 사람의 사용자 ID가 첨부된 댓글을 삽입하려면 사용자만 자신에 대한 댓글 만 삽입할 수 있도록 보호하고 싶을 것입니다. 따라서 두 번째 절을 지정할 수 있도록 an 및 here을 연결 하고 다음과 같이 가정해 보겠습니다. 인증 도트 사용자 ID가 코멘트 도트 사용자 ID와 동일하기를 원하므로 해당 정책을 검토하고 저장해 보겠습니다. 이제 gary는 Ash에게 감사하는 매우 중요한 코멘트를 남길 수 있을 것입니다. Ash 쪽을 새로 고치면 이제 해당 코멘트를 볼 수 있습니다. 나머지 두 작업 에 대한 정책을 추가하여 업데이트하고 삭제할 수 있도록 하고 이러한 정책은 삽입과 정확히 동일하므로 업데이트를 위해 게시물을 볼 수 있고 댓글을 업데이트할 수 있기를 원합니다. 그런 다음 사용 및 확인 시에 정확히 동일한 조건을 붙여넣고 검토를 클릭하여 정책을 저장하고 삭제에도 동일하게 적용하겠습니다. 애플리케이션으로 돌아가면 Gary가 할 수 있는 것을 볼 수 있습니다. uh 그가 Ash의 게시물에 남긴 댓글을 삭제했지만 그는 Ash의 댓글을 삭제할 수 없습니다. 따라서 이 Ash 댓글을 삭제하려고 시도한 다음 가서 Ash 쪽을 새로 고치면 해당 항목이 사라진 것을 볼 수 있으므로 좋습니다. 하지만 한 가지 할 수 있기를 원하는 것은 게시물을 소유한 사람이 게시물에 있는 댓글을 조정할 수 있어야 하고 Ash는 gary의 댓글을 삭제할 수 있어야 하지만 gary는 ash의 댓글을 삭제할 수 없어야 한다는 것입니다. 여기를 보세요. 우리 애플리케이션은 내가 내려와서 gary의 코멘트를 삭제하려고 하면 그 코멘트가 사라진 것처럼 보일 것이라고 가정하고 있습니다. 그러나 다시 새로 고치면 다시 나타납니다. 이는 행 수준 보안으로 인해 해당 코멘트를 수행할 수 없기 때문입니다. 아직 정책을 작성하지 않은 작업이므로 이제 새 정책이 처음부터 생성되고 이는 삭제용이며 사용자가 자신의 게시물에 대한 댓글을 검토할 수 있다고 말할 수 있으므로 이에 대해서도 원할 것입니다. 관련 게시물을 조회하려면 게시물 도트 ID가 댓글 도트 게시물 ID와 동일한 게시물에서 별표를 선택한다고 말할 수 있습니다. 이전 예와 유사하게 게시물 테이블에서 해당 댓글에 대한 게시물 ID를 조회하려고 하지만 이번에는 게시물을 소유한 사람들에게만 이 작업을 허용하고 싶기 때문에 실제로 반환되는 데이터에 관심이 있습니다. 따라서 이 경우 실제로 사용자 ID 열을 선택한 다음 인증 여부를 확인하는 문으로 이를 래핑할 수 있습니다. uid가 이 하위 쿼리에 있으므로 현재 로그인한 사용자가 현재 삭제하려는 댓글에 대한 게시물을 작성한 사용자라면 이를 삭제할 수 있어야 하며 애플리케이션으로 돌아가서 다시 시도하면 됩니다. gary에서 해당 댓글을 삭제하고 새로 고치면 여전히 삭제된 상태이며, gary 측에서 새로 고치면 그는 약간 짜증이 날 수 있지만 해당 댓글도 거기에서 사라져서 이제 우리가 기대하는 방식으로 작동하는 블로그를 갖게 되었습니다. 새 게시물을 작성할 수 있으며 게시되지 않은 경우 다른 사람은 이를 볼 수 없습니다. 게시물을 게시하면 다른 사용자가 해당 게시물을 읽을 수 있고 해당 게시물에 댓글을 추가할 수 있으며 다른 사람들이 작성한 댓글을 볼 수 있습니다. 우리가 볼 수 있는 게시물에 작성된 댓글을 조정하고 심지어 우리가 소유한 게시물을 삭제할 수도 있습니다. 그러면 다른 사용자가 더 이상 멋진 게시물을 볼 수 없게 됩니다. 이것이 바로 Supabase를 사용하여 postgres에서 행 수준 정책을 구현하는 것이 얼마나 쉬운지입니다. 좀 더 자세히 알아보고 싶다면 아래 설명에 인증 문서에 대한 링크가 있으니 YouTube를 확인해 보세요. 이와 같은 더 멋진 동영상을 볼 수 있는 채널을 찾으세요. 트위터에서 우리를 팔로우하고 우리의 새로운 디스코드도 확인하세요. 거기에 아주 멋진 사람들이 몇 명 있습니다. 와서 슈퍼베이스로 무엇을 만들고 있는지 알려주세요. 우리는 그것에 대해 정말 듣고 싶습니다. 감사합니다. [음악] 시청을 위해