항해 4 주차 후기

항해 4주차에는 게시판 CRUD, JWT, AWS S3 이미지 업로드, 스케줄러 를 사용해 보았다.

먼저 게시판 기본 CRUD 기능은 쉽게 구현했다. 다만 엔티티들의 관계를 JPA로 설정하는 부분에 있어서 많은 오류가 있었다.그래서 어떤 상황에서 @OneToMany 와 @ManyToOne을 쓰는지에 대해서 좀 더 공부했었다.

그리고 나에게 가장 어려웠던 기술인 JWT를 구현해봤다. 먼저 어려운 기술인 만큼 왜 JWT를 사용하는지 부터 공부 했었다. JWT를 사용 하는 이유는 다음 아래 설명에 있다.

 

위와 같이 JWT를 왜 쓰는지는 알게 되었다. 하지만 실제로 구현해볼려고 하니 코딩해야하는 부분이 너무 많고 복잡했다.

JWT 동작 구조로 이미지는 다음과 같다.

저 많은 것을 모두 개발할려니 너무 막막했다. 일단 이미지에 맞춰 클래스를 만들어보았다.

기본 JWT 강의에서 나온 내용을 따라서 만들어 보았고, 실행은 되었다. 하지만 동작과정이 제대로 이뤄지고 있는지, 빠진 내용은 없는지, jwt관련 클래스는 정확하게 만들었는지 파악하기는 힘들었다. 그래서 JWT 내용은 따라서 구현 하는데 만족하고 다음 프로젝트에 다시 공부해 적용하기로 했다.

 

JWT를 끝내고 Image upload를 하기 위해서 AWS의 S3를 사용해 보았다.

먼저 S3관련 클래스를 만들어 주었다.

그리고 S3를 실행하기 위한 properies 파일도 추가해 주었다.

S3Config 파일에는 AWS 로 전송하기 위한  값들을 설정해 주었다.

S3Controller에서는 api를 호출해 줄 수 있도록 해주었다.

S3Uploader에서는 실제로 image파일을 aws로 올려주는 작업을 하였다.

S3Upload과정을 성공하면 AWS S3 버킷에 파일이 저장된다.

마지막으로 스케줄러 기능을 만들었다.

 

스케줄러는 그림에 보이는 @Scheduled 어노테이션으로 시간을 정해놓고 그 시간이 되면 자동으로 메소드가 실행되는 기술이다. 나는 1시에 게시글에 댓글 갯수가 0개이면 그 게시글을 삭제하는 메소드를 추가하여 실제로 한 시에 댓글이 0개인 게시물은 모두 삭제가 되었다. 

 

이번주 기능을 만들어 보면서 팀 단위로 백엔드 api를 이렇게 만들어 본 것은 처음이였다. 원래 풀스텍으로 일을 했었는데 이렇게 벡맨드로만 개발을 하려고 하니 어색하기도 했고, 특히 테스트를 어떻게 해야할지 감이 안왔다. 그래서 테스트코드도 작성해보고, postman을 통해서 api요청을 통해 테스트를 진행했다. 그러면서 내가 알지 못했던 것을 알아가는 느낌이 있었다. git관련해서는 팀원들끼리 원활하게 사용하지 못한 것 같다. 서로의 코드가 충돌이 나는게 두려워 아에 다른 폴더를 만들어두고 코딩을 했었다. 그래서 git을 사용하는데 문제는 없었지만 충돌났을때의 대처법은 아직 익숙해지지 못한것 같다. 지금와서 생각해보면 차라리 충돌이 나더라도 그 문제를 해결하면서 배우는게 좀 더 좋지 않았을까 라는 생각을 한다. 어짜피 해야 할 기능이라면 이젠 피하지 말고 직접 부딪혀보는 습관을 가져야겠다.

 

 

https://github.com/EunChangLee/myBlog.git

---

이번주 키워드

* CORS

• CORS란?

브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한합니다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요합니다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절합니다.

이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부릅니다.

그래서 브라우저에서 cross-origin 요청을 안전하게 할 수 있도록 하는 메커니즘입니다.

 

cross-origin이란 다음 중 한 가지라도 다른 경우를 말합니다.

1. 프로토콜 - http와 https는 프로토콜이 다르다.
2. 도메인 - domain.com과 other-domain.com은 다르다.
3. 포트 번호 - 8080포트와 3000포트는 다르다.

• CORS는 왜 필요할까?

CORS가 없이 모든 곳에서 데이터를 요청할 수 있게 되면, 다른 사이트에서 원래 사이트를 흉내낼 수 있게 됩니다. 예를 들어서 기존 사이트와 완전히 동일하게 동작하도록 하여 사용자가 로그인을 하도록 만들고, 로그인했던 세션을 탈취하여 악의적으로 정보를 추출하거나 다른 사람의 정보를 입력하는 등 공격을 할 수 있습니다. 이렇나 공격을 할 수 없도록 브라우저에서 보호하고, 필요한 경우 에만 서버와 협의하여 요청할 수 있도록 하기 위해서 필요합니다.

 

 

• CORS는 어떻게 동작할까?

Simple requests인 경우

1. 서버로 요청을 합니다.
2. 서버의 응답이 왔을 때 브라우저가 요청한 Origin과 응답한 헤더 Access-Control-Request-Headers의 값을 비교하여 유효한 요청이라면 리소스를 응답합니다. 만약 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생합니다.

Simple requests란?

HTTP method가 다음 중 하나이면서

• GET
• HEAD
• POST

자동으로 설정되는 헤더는 제외하고, 설정할 수 있는 다음 헤더들만 변경하면서

• Accept
• Accept-Language
• Content-Language

Content-Type이 다음과 같은 경우

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Simple requqets라고 부릅니다. 이 요청은 추가적으로 확인하지 않고 바로 본 요청을 보냅니다.

 

preflight 요청일 경우

1. Origin헤더에 현재 요청하는 origin과, Access-Control-Request-Method헤더에 요청하는 HTTP method와 Access-Control-Request-Headers요청 시 사용할 헤더를 OPTIONS 메서드로 서버로 요청합니다. 이때 내용물은 없이 헤더만 전송합니다.
2. 브라우저가 서버에서 응답한 헤더를 보고 유효한 요청인지 확인합니다. 만약 유효하지 않은 요청이라면 요청은 중단되고 에러가 발생합니다. 만약 유효한 요청이라면 원래 요청으로 보내려던 요청을 다시 요청하여 리소스를 응답받습니다.

preflight 요청이란?

Simple requests가 아닌 cross-origin요청은 모두 preflight 요청을 하게 되는데, 실제 요청을 보내는 것이 안전한지 확인하기 위해 먼저 OPTIONS 메서드를 사용하여 cross-origin HTTP 요청을 보냅니다. 이렇게 하는 이유는 사용자 데이터에 영향을 미칠 수 있는 요청이므로 사전에 확인 후 본 요청을 보냅니다.

 

• 요청 헤더 목록
  • Origin
  • Access-Control-Request-Method
    • preflight 요청을 할 때 실제 요청에서 어떤 메서드를 사용할 것인지 서버에게 알리기 위해 사용됩니다.
  • Access-Control-Request-Headers
    • preflight요청을 할 때 실제 요청에서 어떤 header를 사용할 것인지 서버에게 알리기 위해 사용됩니다.

 

• 응답 헤더 목록
  
  • Access-Control-Allow-Origin
    • 브라우저가 해당 origin이 자원에 접근할 수 있도록 허용합니다. 혹은 *은 credentials이 없는 요청에 한해서 모든 origin에서 접근이 가능하도록 허용합니다.
  • Access-Control-Expose-Headers
    • 브라우저가 액세스할 수 있는 서버 화이트리스트 헤더를 허용합니다.
  • Access-Control-Max-Age
    • 얼마나 오랫동안 preflight요청이 캐싱 될 수 있는지를 나타낸다.
  • Access-Control-Allow-Credentials
    • Credentials가 true 일 때 요청에 대한 응답이 노출될 수 있는지를 나타냅니다.
    • preflight요청에 대한 응답의 일부로 사용되는 경우 실제 자격 증명을 사용하여 실제 요청을 수행할 수 있는지를 나타냅니다.
    • 간단한 GET 요청은 preflight되지 않으므로 자격 증명이 있는 리소스를 요청하면 헤더가 리소스와 함께 반환되지 않으면 브라우저에서 응답을 무시하고 웹 콘텐츠로 반환하지 않습니다.
  • Access-Control-Allow-Methods
    • preflight`요청에 대한 대한 응답으로 허용되는 메서드들을 나타냅니다.
  • Access-Control-Allow-Headers
    • preflight요청에 대한 대한 응답으로 실제 요청 시 사용할 수 있는 HTTP 헤더를 나타냅니다.

 

출처 :https://hannut91.github.io/blogs/infra/cors