workbook: 3주차 워크북 인증 (스터디 후)

UMC-Inha · Oct 11, 2024 · b4df736 · b4df736
1 parent bbd15cd
commit b4df736
Show file tree

Hide file tree

Showing 6 changed files with 32 additions and 4 deletions.
diff --git a/keyword/chapter03/images/트러블슈팅-문제탐색-1.png b/keyword/chapter03/images/트러블슈팅-문제탐색-1.png
diff --git a/keyword/chapter03/images/트러블슈팅-문제탐색-2.png b/keyword/chapter03/images/트러블슈팅-문제탐색-2.png
diff --git a/keyword/chapter03/images/트러블슈팅-문제해결.png b/keyword/chapter03/images/트러블슈팅-문제해결.png
diff --git a/keyword/chapter03/images/트러블슈팅-에러.png b/keyword/chapter03/images/트러블슈팅-에러.png
diff --git a/keyword/chapter03/keyword.md b/keyword/chapter03/keyword.md
@@ -85,4 +85,15 @@
     - Express 공식 예제를 ES Module 방식으로 바꾸어 실행해주었다.
 1. package.json의 scripts에 npm install --save-dev nodemon 추가
     ![images/실습2-nodemon.png](images/실습2-nodemon.png)
-    - 프로젝트를 수정하고 저장할 때마다 서버를 자동으로 재시작하게 만들어 주었다.
+    - 프로젝트를 수정하고 저장할 때마다 서버를 자동으로 재시작하게 만들어 주었다.
+
+**⚡ 작은 트러블 슈팅**
+1. **이슈**<br/>
+    프로젝트 중 기존에 설치해둔 node, npm 버전이 각각 20.16.0, 10.8.3인 걸 확인한 후 워크북에 명시된 대로 “npm install express@^5.0.0-0”을 입력해 express@^5.0.0-0을 설치하려 했는데 사진과 같은 에러가 발생하며 설치에 실패했다.
+    ![images/트러블슈팅-에러.png](images/트러블슈팅-에러.png)
+2. **문제 & 해결**
+    ![images/트러블슈팅-문제탐색-1.png](images/트러블슈팅-문제탐색-1.png)
+    검색을 해보았더니 한 사이트에서 [email protected]는 아직 정식 릴리스된 게 아니어서 해당 에러가 발생한 것이라는 글을 보았지만 npm 홈페이지에서 5.x 버전이 정식 릴리즈 된 것을 확인하였다.
+    ![images/트러블슈팅-문제탐색-2.png](images/트러블슈팅-문제탐색-2.png)
+    ![images/트러블슈팅-문제해결.png](images/트러블슈팅-문제해결.png)
+    그래서 express@^5.0.0-0이 아닌 [email protected](npm 홈페이지에 나와있었음)을 설치해보았더니 성공적으로 설치가 되었다. 버전 끝에 “-0”이 붙느냐의 차이었고 찾아보니 “-0”는 프리릴리즈(pre-release) 태그를 나타내며 일반적으로 버전 뒤에 붙는 -0 태그는 해당 패키지가 아직 정식 릴리즈가 아닌 개발 버전임을 의미한다고 한다. 즉, [email protected]는 5.0.0 정식 버전이 나오기 전에 배포된 테스트 버전인 것이다. 워크북이 만들어질 당시에는 5.0.0이 프리릴리즈였나 보다. 
diff --git a/mission/chapter03/mission.md b/mission/chapter03/mission.md
@@ -164,8 +164,8 @@
           "message": "string",
           "result": [
         	  "restaurantName": "string",
-        	  "completedMission": {
-        		  "completedMissionId": 1,
+        	  "ongoingMission": {
+        		  "ongoingMissionId": 1,
         		  "introduction": "string",
         		  "points": 500
         	  }
@@ -259,4 +259,21 @@
         "accessToken": "string"
       }
     }
-    ```
+    ```
+
+**스터디 후 더 공부한 내용**
+1. Access token을 Bearer로 감싸서 보내는 이유
+    - 간단하고 안전한 전송 방식
+        - Bearer 토큰은 HTTP 요청의 Authorization 헤더에 포함되어 서버로 전달되는데 이는 별도의 복잡한 인증 과정 없이 토큰을 소지한 사람만이 리소스에 접근할 수 있도록 한다.
+            - ex. Authorization: Bearer <access_token>
+    - OAuth 2.0 표준 준수
+        - OAuth 2.0 표준은 Bearer 토큰을 사용하여 액세스 권한을 부여하고 이를 통해 서버는 해당 토큰의 유효성을 확인할 수 있다.
+    - 보안 강화 및 유효성 검증
+        - Bearer 방식은 주로 SSL/TLS와 같은 안전한 통신 프로토콜과 함께 사용되어 토큰이 중간에서 도청되는 위험을 방지한다.
+    - 인증 간소화
+        - 클라이언트는 별도의 사용자 인증 정보를 매번 입력할 필요 없이 서버에 Bearer 토큰을 전송하기만 하면 된다. 서버는 해당 토큰의 유효성만 확인하면 그 클라이언트의 신원을 확인한 것으로 간주한다.
+2. 데이터베이스에서 id를 AUTO_INCREMENT(고유한 숫자 식별자(ID)를 자동으로 생성)로 설정했을 경우, Request Body에 id 필드를 넣어 값을 지정해주어야 되는지
+    - Request Body에 id 포함 여부
+        - **포함하지 않아야 한다**. 데이터베이스가 새로운 레코드가 생성될 때마다 자동으로 고유한 id를 부여하기 때문에 클라이언트가 직접 id를 지정할 필요가 없다.
+    - Response Body에 id 포함 여부
+        - **포함하는 것이 좋다**. 새로운 리소스가 생성된 후, 서버는 데이터베이스에 의해 생성된 id를 응답으로 반환하는 것이 일반적이다. 클라이언트가 생성된 리소스의 id를 확인하고 이후에 이를 참조하거나 사용할 수 있도록 도와준다.