[feat] differ access depends on permissions#132
Conversation
📝 WalkthroughWalkthroughNotion 기반 그룹 생성 페이지에서 초기 역할 권한 배열을 조정했습니다. 매니저 권한에 ROLE_REVOKE를 추가했고, 멤버의 기본 권한을 빈 배열에서 MEMBER_UPDATE로 변경했습니다. 외부 API 호출, 제어 흐름, 공개 인터페이스 변경은 없습니다. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying groups-fe with
|
| Latest commit: |
ac76328
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://88526065.groups-fe.pages.dev |
| Branch Preview URL: | https://131-feat-differ-access-depen.groups-fe.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx (2)
79-83: 역할 생성 실패 처리 강화 및 병렬화 제안현재는 두 createRole 호출 중 하나라도 실패해도 다음 단계로 진행합니다. 최소한 하나 이상 실패 시 사용자에게 알려주고 복구 경로(재시도) 제공을 권장합니다. 또한 의존성이 없다면 병렬 실행으로 지연을 줄일 수 있습니다.
예시(diff: 실패 시 알림/로그를 분리하고 병렬화):
- try { - await createRole(groupUuid, manager.name, manager.permissions); - await createRole(groupUuid, member.name, member.permissions); - } catch (error) { - console.error("Failed to create role:", error); - } + const results = await Promise.allSettled([ + createRole(groupUuid, manager.name, manager.permissions), + createRole(groupUuid, member.name, member.permissions), + ]); + const failures = results.filter(r => r.status === "rejected"); + if (failures.length > 0) { + console.error("Failed to create one or more roles:", failures); + // TODO: 사용자에게 역할 생성 실패를 안내하고 재시도 옵션 제공 + }
71-72: 매니저 권한에 ROLE_REVOKE 추가 — 백엔드·프론트 가드 점검 요청아래 사항을 확인 및 조치해주세요.
• 백엔드
– 역할 회수(Revoke) API가 ROLE_REVOKE 권한을 실제로 체크하는지 확인 (권한 없을 시 403 반환).
• 프론트엔드
– 역할 회수 UI/버튼이 ROLE_REVOKE 보유 시에만 노출·활성화되는지 확인.
– 역할 부여 UI/버튼은 ROLE_GRANT 보유 시에만 노출·활성화되는지 확인.
(현재authorityChecker(userRole.permissions, ["ROLE_GRANT","ROLE_REVOKE"])로 두 권한을 동시에 전달하고 있으니, 각각 별도 체크여부를 검토해주세요.)
• 권한 기본값 상수화 권장
– 여러 파일에 중복 정의된 권한 리스트는 드리프트 위험이 있어,DEFAULT_MANAGER_PERMISSIONS등의 상수로 모듈 스코프(또는 공용 constants 파일)에 분리하는 것을 제안합니다.적용 예 (CreateGroupNotionPage.tsx):
@@ src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx - const manager = { - name: "manager", - permissions: [ - RolePermissions.MEMBER_UPDATE, - RolePermissions.MEMBER_DELETE, - RolePermissions.ROLE_UPDATE, - RolePermissions.ROLE_GRANT, - RolePermissions.ROLE_REVOKE, - ], - }; + const manager = { + name: "manager", + permissions: DEFAULT_MANAGER_PERMISSIONS, + };constants.ts (공용 위치):
type RolePermission = typeof RolePermissions[keyof typeof RolePermissions]; export const DEFAULT_MANAGER_PERMISSIONS: RolePermission[] = [ RolePermissions.MEMBER_UPDATE, RolePermissions.MEMBER_DELETE, RolePermissions.ROLE_UPDATE, RolePermissions.ROLE_GRANT, RolePermissions.ROLE_REVOKE, ];검증 스크립트 예시:
# 권한 사용처·가드 점검 rg -nP -C3 --type=ts 'hasPermission\(\s*.*ROLE_REVOKE' src rg -nP -C3 --type=ts 'hasPermission\(\s*.*ROLE_GRANT' src rg -nP -C2 --type=ts 'authorityChecker' src/pages/manage/pages/members/sections/memberManagement/index.tsx
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx (1)
src/types/interfaces.ts (1)
RolePermissions(34-44)
| permissions: [RolePermissions.MEMBER_UPDATE], | ||
| }; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
멤버 기본 권한을 MEMBER_UPDATE로 상향 — 권한 범위 재확인 권고
MEMBER_UPDATE의 범위가 “자기 자신 정보 수정”으로 제한돼 있는지 확인이 필요합니다. 타인 멤버 정보/역할까지 갱신 가능한 의미라면 기본 부여는 위험합니다. 서버는 주체 검증(userId === me)으로 강제하고, 프런트는 해당 권한으로 노출되는 UI(예: 멤버 편집 버튼)가 자기 자신일 때만 활성화되도록 가드가 필요합니다.
또한 멤버 기본 권한 변경은 다른 그룹 생성 플로우(노션 외 경로)에도 동일하게 반영되어야 합니다. 중복 정의를 방지하려면 공용 기본 권한 상수로 추출하는 것을 권장합니다.
적용 예(diff: 해당 구간에서 상수 사용으로 치환):
@@
- const member = {
- name: "member",
- permissions: [RolePermissions.MEMBER_UPDATE],
- };
+ const member = {
+ name: "member",
+ permissions: DEFAULT_MEMBER_PERMISSIONS,
+ };상수 정의(파일 상단에 추가):
export const DEFAULT_MEMBER_PERMISSIONS: RolePermission[] = [
RolePermissions.MEMBER_UPDATE,
];검증 스크립트(멤버 업데이트 권한이 노출/행동 가드에 연결되는지 점검):
🏁 Script executed:
#!/bin/bash
# MEMBER_UPDATE 사용처와 가드 확인
rg -nP -C3 --type=ts 'MEMBER_UPDATE' src
# "본인만 편집" 제약이 구현되어 있는지 후보 패턴 검색
rg -nP -C2 --type=ts '(currentUser|me|isSelf).*MEMBER_UPDATE|MEMBER_UPDATE.*(currentUser|me|isSelf)' srcLength of output: 2556
멤버 기본 권한 MEMBER_UPDATE 부여 시 UI/서버 가드 미구현 확인 — 필수 수정 필요
rg 스크립트 결과,
- CreateGroupNotionPage.tsx(76–77) 및 invitation 컴포넌트에서
RolePermissions.MEMBER_UPDATE사용처는 확인되나 - “본인만 편집” 제약을 위한
currentUser/me/isSelf검사 로직이 전혀 구현되어 있지 않습니다.
해당 권한이 타인 정보·역할 변경까지 허용될 가능성이 있어 보안상 치명적이므로,
- 서버 측에서
userId === me검증 로직이 반드시 적용되었는지 확인 및 보강 - 프런트엔드에서 MEMBER_UPDATE 권한 UI(예: 멤버 편집 버튼) 노출 시 본인 여부를 함께 체크하는 가드 추가
또한, 향후 다른 그룹 생성 플로우에서도 중복 정의를 방지하기 위해 기본 권한을 공용 상수로 추출할 것을 권장합니다.
— 수정 필요 위치
- src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx (member 기본 권한 정의)
- src/pages/manage/pages/members/sections/invitation/index.tsx (권한 검사 후 UI 노출 로직)
- 서버 코드(userId===me 검증)
- 공용 상수 정의: src/types/interfaces.ts 또는 별도 권한 설정 파일
— 예시 diff
@@ src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx
- const member = {
- name: "member",
- permissions: [RolePermissions.MEMBER_UPDATE],
- };
+ const member = {
+ name: "member",
+ permissions: DEFAULT_MEMBER_PERMISSIONS,
+ };// src/types/interfaces.ts 또는 별도 권한 설정 파일
export const DEFAULT_MEMBER_PERMISSIONS: RolePermission[] = [
RolePermissions.MEMBER_UPDATE,
];— UI 가드 예시
{user.id === me.id && authorityChecker(userRole.permissions, ["MEMBER_UPDATE"]) && (
<EditMemberButton />
)}위 보안 이슈는 즉시 반영이 필요합니다.
🤖 Prompt for AI Agents
In src/pages/createGroup/pages/notion/CreateGroupNotionPage.tsx around lines
76-77, the default MEMBER_UPDATE permission is assigned without any self-checks;
add a shared constant for default member permissions (e.g., export
DEFAULT_MEMBER_PERMISSIONS in src/types/interfaces.ts or a new permissions file)
and replace the inline array with that constant; then update the frontend
components (notably
src/pages/manage/pages/members/sections/invitation/index.tsx) to only render
MEMBER_UPDATE UI controls when the current user is the same as the target user
(check me.id or currentUser.id === user.id) AND the authority check for
MEMBER_UPDATE passes; finally ensure server-side authorization enforces userId
=== me (or equivalent) before allowing MEMBER_UPDATE changes so the backend
rejects requests that attempt to modify other users regardless of client-side
guards.
1 participant
Summary by CodeRabbit