경북대 FE_정지원 6주차 Step3~4

.github/workflows/ci.yml

@@ -0,0 +1,48 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+    # paths: // path는 특정 폴더에 변경사항이 생겼을 때 작동하도록 설정할 수 있음
+    #   - "services/**"
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout Repository
+        uses: actions/checkout@v2
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v2
+        with:
+          node-version: "18"
+
+      - name: Install Dependencies
+        run: npm install
+
+      - name: Build
+        run: npm run build
+
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout Repository
+        uses: actions/checkout@v2
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v2
+        with:
+          node-version: "18"
+
+      - name: Install Dependencies
+        run: npm install
+
+      - name: Run Test
+        run: npm test

.gitignore

@@ -0,0 +1 @@
+/node_modules

README.md

@@ -1 +1,95 @@
-# react-deploy
+# 카카오 테크 캠퍼스 - 배포 & 협업
+
+#### 🚀 0단계 - 기본 코드 준비
+
+- [x] 기능을 구현하기 전 README.md에 구현할 기능 목록을 정리해 추가한다.
+
+#### 🚀 1단계 - API 명세 협의 & 반영
+
+- [x] 팀 내에서 일관된 기준을 정하여 API 명세를 결정한다.
+
+      명세에 맞게 MSW 로 테스트
+      - [x] 로그인, 회원가입 API
+      - [x] 카테고리 목록 조회 API
+      - [x] 주문 생성 및 목록 조회 API
+
+- [x] 팀 내에 배포 될 API가 여러개 일 경우 상단 네비게이션 바에서 선택 가능하게 한다.
+
+- [x] 프론트엔드의 경우 배포와 사용자가 팀 내 여러 서버 중 하나를 선택하여 서비스를 이용
+
+- [x] 팀내 백엔드 엔지니어의 이름을 넣고, 이름을 선택하면 해당 엔지니어의 API로 API통신을 하게 한다.
+
+- [x] 기본 선택은 제일 첫번째 이름으로 한다.
+
+#### 🚀 2단계 - 배포하기
+
+- [x] 세가지 방법 중 본인이 원하는 방식으로 배포한다.
+      (단, 가능하면 최대한 방법 1, 3번으로 진행하고 CI/CD를 구축하는 것을 권장해요)
+
+#### 🚀 3단계 - 포인트
+
+- [x] 상품 구매에 사용할 수 있는 포인트 기능을 구현한다.
+
+- [x] 포인트는 사용자별로 보유한다.
+
+- [x] 포인트 차감 방법 등 나머지 기능에 대해서는 팀과 논의하여 정책을 결정하고 구현한다.
+
+      -[x] 포인트 조회 (/api/points)
+      -[x] 주문하기 API 수정 (주문 시 points 입력 값을 넘겨줘서 서버에서 최종 결제 금액의 5% 포인트 적립)
+
+#### 🚀 4단계 - 질문의 답변을 README에 작성
+
+- [x] 질문 1. SPA 페이지를 정적 배포를 하려고 할 때 Vercel을 사용하지 않고 한다면 어떻게 할 수 있을까요?
+      답변 :
+
+      **호스팅 : 서버 컴퓨터의 전체 또는 일부를 임대해주는 서비스**
+
+      1. Github Pages
+            GitHub 레포지토리에 프로젝트를 푸시한 후, GitHub Pages 기능을 사용하여 정적 웹사이트를 호스팅할 수 있습니다. 레포지토리의 설정(Setting)에서 GitHub Pages를 활성화하고, 배포할 브랜치를 선택하면 됩니다. (/root)
+
+      2. AWS S3 + CloudFront
+            AWS S3에 정적 파일을 업로드하고, CloudFront를 사용하여 CDN을 통해 배포할 수 있습니다. S3 는 정적 웹 사이트 호스팅을 하는데 S3에 저장해 놓은 정적 리소스들은 내용이 비워진 일종의 '틀(Frame)' 역할을 하고, API 호출을 통해 불러오는 동적 데이터들은 정적인 파일들을 저장하는 저장소인 S3에 저장하지 못하고, 별도의 백엔드 서버를 통해 제공됩니다. 백엔드 서버에서 불러오는 동적인 데이터들은 그 틀을 채우는 '내용'의 역할을 합니다.
+
+      3.Netlify
+            Netlify는 쉽게 정적 사이트 호스팅을 할 수 있는 플랫폼으로 나와있었습니다. GitHub, GitLab 또는 Bitbucket과 연동하여 자동 배포를 지원합니다. 프로젝트를 연결하고, 빌드 명령과 배포 디렉토리를 설정하면 간편하게 배포할 수 있습니다.
+
+- [x] 질문 2. CSRF나 XSS 공격을 막는 방법은 무엇일까요?
+      답변 :
+
+            CSRF (Cross Site Request Forgery) : 사이트 간 요청 위조
+            CSRF 는 웹 보안 취약점의 일종이며, 사용자의 의지와는 무관하게 공격자가 특정 웹사이트에 데이터 수정,삭제,등록을 요청하게 하는 공격입니다.
+
+            CSRF 방어 방법 - 사용자 입장
+                  이상한 URL 를 클릭하지 않기.
+
+            CSRF 방어 방법 - 웹 개발자 입장
+                  1. Referer check (리퍼러 체크):
+                  HTTP 요청 헤더(request header) 정보에서 Referrer 정보를 확인할 수 있습니다. 보통이라면 호스트(host)와 Referrer 값이 일치하므로 둘을 비교합니다.
+
+                  2. CSRF 토큰 사용:
+                  사용자 세션에 임의의 값을 저장해 모든 요청마다 해당 값을 포함해 전송하도록 합니다. 서버에서 요청을 받을때마다, 세션에 저장된 값과 요청으로 전송된 값이 일치하여 검증하여 방어하는 방법입니다.
+
+                  3. POST 요청 사용:
+                        중요한 작업은 GET 요청이 아닌 POST 요청을 통해 처리하여, CSRF 공격을 어렵게 만듭니다.
+
+            XSS(Cross-Site-Scripting) : 다른 웹사이트와 정보를 교환하는 것
+            XSS 공격은 간단하게 말하자면, 웹 애플리게이션에서 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입하는 것을 말합니다.
+
+            XSS 방어 방법
+                  1. 입력 데이터 검증 및 인코딩
+                        정규표현식 사용해 특수문자를 입력받지 못하도록 처리하거나 입력값 특수문자를 문자열로 치환하기
+                  2. HTTPOnly 및 Secure 플래그 설정
+                        쿠키에 HTTPOnly 및 Secure 플래그를 설정하여, 클라이언트 측 스크립트에서 쿠키에 접근할 수 없도록 합니다.
+                  3. Content Security Policy (CSP) 설정
+                        CSP를 설정하여, 신뢰할 수 있는 출처에서만 스크립트를 로드하도록 제한합니다. 이를 통해 악성 스크립트의 실행을 방지할 수 있습니다.
+
+- [x] 질문 3. 브라우저 렌더링 원리에대해 설명해주세요.
+
+      답변 : 1. 사용자의 요청에 따라 HTML, CSS 파일이 파서에 렌더링 엔진의 파서에 의해 DOM, CSSOM 트리로 변환되고 렌더 트리로 결합됩니다. 이 렌더 트리를 기반으로 브라우저가 웹페이지를 출력합니다.
+
+            2. 자바스크립트는 렌더링 엔진이 아닌 자바스크립트 엔진이 처리합니다. HTML 파서가 script 태그를 만나면 DOM 생성 프로세스를 중지하고 자바스크립트 엔진으로 제어 권한을 넘겨 자밥스크립트를 실행합니다. 완료되면 브라우저가 중지했던 시점부터 다시 DOM 생성을 재개합니다.
+
+            3. DOM 이나 CSSOM 의 수정될 때 repaint, reflow 가 발생합니다.
+             리플로우는 요소의 크기나 위치가 변경될 때 발생하며, 리페인트는 색상이나 스타일이 변경될 때 발생합니다.
+
+            브라우저 렌더링 과정에서 렌더링 성능을 향상시키기 위해 DOM 조작을 최소화해야 합니다.

babel.config.js

@@ -0,0 +1,7 @@
+module.exports = {
+  presets: [
+    '@babel/preset-env',
+    '@babel/preset-react',
+    '@babel/preset-typescript', // TypeScript를 위한 프리셋
+  ],
+};

craco.config.js

@@ -0,0 +1,16 @@
+const path = require('path');
+
+module.exports = {
+  webpack: {
+    alias: {
+      '@': path.resolve(__dirname, 'src'),
+    },
+  },
+  jest: {
+    configure: {
+      moduleNameMapper: {
+        '^@/(.*)$': '<rootDir>/src/$1',
+      },
+    },
+  },
+};