Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

9주차 미션 / 서버 1조 박지원 #3

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

9주차 미션 / 서버 1조 박지원 #3

wants to merge 3 commits into from

Conversation

david-parkk
Copy link
Member

안녕하세요 서버 1조 박지원(david-parkk)입니다. 😄
이번주에는 jwt를 통한 인증 인가 처리와 페이징 처리에 대해서 학습하였습니다.
미션을 진행하면서 생각해본 내용에 대해 아래 적었습니다(사실 보단 제 주장에 가깝습니다.)

미션 진행도

  • JWT 인증 인가 처리
  • 패이징처리
  • Refresh Token

API

  • 회원조회
  • 회원생성
  • 닉네임 수정
  • 회원 변경
  • 회원 삭제
  • 회원전부조회
  • 상점조회
  • 상점등록
  • 카테고리조회
  • 상점+카테고리 조회
  • 로그인(인증 인가를 위해 추가됨)

1. JWT의 인코딩 과 전자 서명 🔑

  • 첫번째로 JWT는 데이터를 인코딩하여 만들게 됩니다. 이때 인코딩은 일반적으로는 base64를 통해 인코딩되기 때문에 JWT을 가지고 있는 누구나 토큰내용을 볼 수 있게 됩니다.
  • 따라서 JWT에는 민감 정보가 들어가선 안됩니다.
  • 두번째로 JWT는 전자 서명 부분이 존재합니다.
  • 전자 서명은 비밀키로 해시값을 암호화하여 공개키로 해시값을 복호화할 수 있습니다.(해시값이기 때문에 원본 데이터는 알 수 없지만 데이터의 무결성은 보장 할 수 있게 됩니다.
  • 그러나 여기서 생각해 볼 문제가 있습니다. JWT을 제공한 서버외에는 JWT의 무결성을 확인할 필요가 있을까요?
  • 사용자는 JWT의 내부를 알 필요가 없습니다.(단지 인증 인가를 위한 신분증일뿐 신분증 내부까지 알 필요가 없듯이)
  • 그러면 비대칭 암호화 방식을 굳이 JWT에서 채택할 필요가 있을까요?(대칭키가 비대칭키보다 성능적으로 우수하고 알려져 있음)
  • 다른 서버에서 JWT의 무결성을 확인해야 하는 경우라면 비대칭키 암호화가 납득되게 됩니다.(MSA, SSO)

2. Offset 이 느린 이유 📝

  • 페이징 처리에서 Offset 방식은 느리다고 알려져 있습니다.
  • 시간이 O(N)으로 소요된다고 하는데, 해당 성능이 나올 수 밖에 없는 이유가 있을까요?(indexing을 사용하면 안될까?)
  • 일단 Offset은 Position을 지정한다고 생각해봅시다.
  • Position을 지정하기 위해서는 쿼리의 결과가 실행되기 전까지 Position을 알 수 없습니다.
SELECT *
  FROM dbtable
  WHERE status = 'Y'
  ORDER BY CODE 
  LIMIT 20 OFFSET 10
  • 위 쿼리를 실행한다고 생각해보면, CODE 기준으로 정렬될 때까지, STATUS가 'Y'인지 쿼리를 실행하지 않으면 그중 10번째 Position이 어딘지 알 수 없습니다.(indexing한 속성에 대해서는 다를 수 있음)
  • 따라서 해당 쿼리를 실행한 결과인 서브쿼리에 대해서 일일이 10개를 셀 수 밖에 없습니다.(느린 연산이 되게 된다)

jaeuk520
jaeuk520 reviewed May 31, 2024
View reviewed changes
Copy link
Contributor

@jaeuk520 jaeuk520 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이번주도 고생 많으셨습니다 :)

먼저 작성해주신 내용에 대해 짧게 답변해드릴게요!

  1. JWT를 제공한 서버외에는 JWT의 무결성을 확인할 필요가 있을까요?
  • 현재 JwtProvider 클래스에서는 대칭 키 형식의 암호화 알고리즘인 HS256 을 사용하고 있어요. 따라서 비대칭 형식이 아닙니다...!! 따라서 내가 만든 서버가 아닌 외부 서버와의 통신이 필요한 경우에는 말씀해주신대로 비대칭 키를 사용하는 것이 더 좋을 수가 있겠죠. (여러 서버가 통신하는 경우일지라도 모두 내가 만든 서버라면 대칭키를 사용해도 된다고 생각합니다.)
  1. Offset이 느린 이유

src/main/java/kuit/server/config/SecurityConfig.java
.sessionManagement((sessionManagement) ->
sessionManagement.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
);
.csrf().disable()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'csrf()' is deprecated since version 6.1 and marked for removal
해당 방식이 6.1 버전부터 deprecated 되어 이전 코드 대로 작성해주시는게 좋을 것 같아요 :)

src/main/java/kuit/server/dao/MemberDao.java
* 유저 전부 조회
**/
public List<Member> findAll(long memberId, int size) {
String sql = "select member_id, name, nickname, password, phone_num, email from member where member_id >=:member_id limit :size";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

기획적인 측면에서는 페이징 처리가 유저 조회가 아닌 상점 조회 부분에 들어가는게 더 좋을 것 같아요 👍

@david-parkk
Copy link
Member Author

잘못 이해한 부분이 있었네요.. 코멘트 감사합니다 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jaeuk520 jaeuk520 jaeuk520 left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@david-parkk @jaeuk520