Feature: 페이지 접근 보호 시스템 구축 및 레이아웃 통일#13
Conversation
- 로그인 인증 상태 체크 로직 추가 - App 컴포넌트를 PrivateRoute로 감싸 주요 페이지 보호 - 로그인/콜백/온보딩 페이지는 공개 라우트로 분리
- 로그인, 온보딩 페이지가 App 컴포넌트 밖으로 가면서 발생한 레이아웃 이슈 해결 - 로그인 페이지에 GlobalLayout 개별 적용 - 온보딩 페이지에 GlobalLayout 개별 적용
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @woo-dev-log, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request focuses on enhancing the application's security by introducing a robust page access protection system. It involves creating a dedicated PrivateRoute component, restructuring the React Router configuration to enforce authentication for protected areas, and ensuring layout consistency across all pages, including public-facing ones.
Highlights
- Authentication System: I've implemented a new
PrivateRoutecomponent that checks for user authentication (currently viasession_idinlocalStorage) and automatically redirects unauthenticated users to the login page using React Router'sNavigatecomponent. - Router Structure Improvement: The application's routing has been refactored in
src/main.tsx. The main<App />component is now wrapped by thePrivateRoute, ensuring that all core application pages require authentication. Public routes like/loginand/onboardinghave been moved to the top level to allow unauthenticated access. - Layout Consistency for Public Pages: To address a layout issue where public pages lost their consistent UI after the routing changes, I've explicitly applied the
GlobalLayoutcomponent to bothLoginPageandOnboardingPage. This ensures a unified look and feel across all pages, while disabling header and bottom navigation for these specific public views.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
안녕하세요. 페이지 접근 보호를 위한 PrivateRoute 도입과 레이아웃 통일 작업을 잘 보았습니다. 인증이 필요한 라우트와 공개 라우트를 명확하게 분리하여 애플리케이션의 보안 구조를 강화한 점이 인상적입니다.
코드 리뷰는 프로젝트 스타일 가이드에 따라 한국어로 작성되었으며, 특히 테스트 코드 작성 의무화 (스타일 가이드 12번째 줄) 조항을 중점적으로 확인했습니다. 이를 바탕으로 몇 가지 개선점을 제안합니다.
- 보안 강화: 현재
localStorage를 사용한 토큰 관리는 XSS 공격에 취약할 수 있습니다.httpOnly쿠키를 사용하는 방안을 고려해보시는 것이 좋습니다. - 유지보수성 향상: 코드에 하드코딩된 문자열을 상수로 관리하고, 라우팅 구조 변경으로 인해 발생한 불필요한 코드를 정리하면 유지보수성이 향상될 것입니다.
- 테스트 코드 추가: 스타일 가이드에 따라, 새로 추가된
PrivateRoute컴포넌트에 대한 테스트 코드를 작성하여 로직의 안정성을 보장해야 합니다.
자세한 내용은 각 파일에 남긴 코멘트를 확인해주세요.
| export const PrivateRoute = ({ children }: PrivateRouteProps) => { | ||
| // TODO: 현재 백엔드에서 로그인 응답을 sessionId로 제공하고 있어 | ||
| // 임시로 session_id로 인증 체크 중. 추후 access_token으로 통일 예정 | ||
| const token = localStorage.getItem('session_id'); |
There was a problem hiding this comment.
보안 상 localStorage에 세션 ID와 같은 민감한 데이터를 저장하는 것은 XSS(Cross-Site Scripting) 공격에 취약점을 노출할 수 있습니다. localStorage는 JavaScript를 통해 쉽게 접근할 수 있어, 악성 스크립트가 주입될 경우 토큰이 탈취될 위험이 있습니다.
권장 사항:
httpOnly 속성을 적용한 쿠키를 사용하여 토큰을 관리하는 것을 강력히 권장합니다. httpOnly 쿠키는 JavaScript로 접근할 수 없기 때문에 XSS 공격으로부터 토큰을 효과적으로 보호할 수 있습니다.
| export const PrivateRoute = ({ children }: PrivateRouteProps) => { | ||
| // TODO: 현재 백엔드에서 로그인 응답을 sessionId로 제공하고 있어 | ||
| // 임시로 session_id로 인증 체크 중. 추후 access_token으로 통일 예정 | ||
| const token = localStorage.getItem('session_id'); | ||
|
|
||
| return token ? <>{children}</> : <Navigate to="/login" replace />; | ||
| }; No newline at end of file |
There was a problem hiding this comment.
프로젝트 스타일 가이드에 따르면 모든 코드에 자동화된 테스트가 필요합니다.1 PrivateRoute 컴포넌트는 애플리케이션의 핵심 인증 로직을 담당하므로, 안정적인 동작을 보장하기 위한 테스트 코드를 작성하는 것이 매우 중요합니다.
아래와 같은 시나리오에 대한 테스트 케이스를 추가하는 것을 권장합니다.
- 인증된 사용자: 토큰이 존재할 경우,
children이 정상적으로 렌더링되는지 확인합니다. - 인증되지 않은 사용자: 토큰이 없을 경우,
/login경로로 올바르게 리다이렉트되는지 확인합니다.
Style Guide References
Footnotes
| export const PrivateRoute = ({ children }: PrivateRouteProps) => { | ||
| // TODO: 현재 백엔드에서 로그인 응답을 sessionId로 제공하고 있어 | ||
| // 임시로 session_id로 인증 체크 중. 추후 access_token으로 통일 예정 | ||
| const token = localStorage.getItem('session_id'); |
There was a problem hiding this comment.
인증 토큰의 키로 사용된 'session_id'가 매직 문자열(magic string)로 하드코딩되어 있습니다. 이는 오타 발생 가능성을 높이고, 향후 키 이름이 변경될 경우 여러 곳을 수정해야 하는 등 유지보수를 어렵게 만듭니다.
별도의 상수 파일(예: src/constants/auth.ts)에 키를 상수로 정의하고 이를 가져와 사용하는 것이 좋습니다. 이렇게 하면 코드의 가독성과 안정성이 크게 향상됩니다.
개선 예시:
// src/constants/auth.ts
export const AUTH_TOKEN_KEY = 'session_id';
// src/components/auth/PrivateRoute.tsx
import { AUTH_TOKEN_KEY } from '@/constants/auth';
// ...
const token = localStorage.getItem(AUTH_TOKEN_KEY);| { | ||
| path: "/login", | ||
| element: <LoginPage />, | ||
| }, | ||
| { | ||
| path: "/callback", | ||
| element: <AuthCallbackPage />, | ||
| }, | ||
| { | ||
| path: "/onboarding", | ||
| element: <OnboardingPage />, | ||
| }, |
There was a problem hiding this comment.
로그인 및 온보딩 페이지를 App 컴포넌트의 하위 라우트에서 최상위 라우트로 분리한 구조 변경은 페이지 접근 제어를 명확하게 만들어주는 좋은 시도입니다.
다만 이로 인해 App.tsx 파일 내 layoutGroups 객체에 정의된 /login과 /onboarding 경로에 대한 레이아웃 분기 로직이 더 이상 사용되지 않는 코드가 되었습니다. 코드의 혼란을 방지하고 유지보수성을 높이기 위해, App.tsx에서 해당 경로 관련 코드를 제거하는 후속 조치가 필요해 보입니다.
1 participant
📌 PR 종류 (PR Type)
📝 요약 (Summary)
페이지 접근 보호를 위한 PrivateRoute 시스템 구축 및 공개 페이지 레이아웃 복구
🔍 상세 내용 (Describe your changes)
1. PrivateRoute 컴포넌트 구현
2. 라우터 구조 개선
3. 레이아웃 이슈 해결
📸 스크린샷 (필수)
✅ 확인 사항 (CheckList)
💬 기타 참고사항 (Optional)
테스트 방법
/,/explore,/my등 접근 시/login으로 리다이렉트 확인추후 개선 예정
session_id로 인증 체크하고 있으나, 추후access_token으로 통일 예정