1. 로그인 구현 종류

1) 쿠키 vs 세션

1) 쿠키

: 브라우저에 정보를 저장할 수 있는 작은 공간
-> 사용자 식별 아이디, 설정값(다크모드 설정),
BUT. 비밀번호와 같은 개인정보는 넣으면 안됌
사용자가 변경가능하여 취약함

2) 세션

:서버가 특정 클라이언트와의 연속적인 상호작용 상태를 식별하고 유지하기 위해 저장하는 서버 측 상태 정보, 로그인 요청이 들어올 때마다 DB에서 일치하는 세션아이디를 확인
-> 사용자가 값을 바꿀 수 없음 사용자 브라우저가 아닌 서버에서 확인하는 용도
세션 식별아이디가 영어와 숫자를 랜덤하게 조합한 것이라고는 하나 해킹의 위험이 있음

3) JWT
: 사용자의 정보를 인코딩하여 토큰으로 활용한 것
(DB 필요 없음, 조작하지 못하게 처리되어 있음)
-> 정보를 인코딩한 것이기 때문에 디코딩하면 모든 정보를 읽을 수 있음

2) 세션 로그인

1. 로그인 요청 -> 사용자가 아이디와 비번을 입력
2. 서버 검증 -> 서버가 DB에 저장된 정보와 비교
3. 세션 생성 -> 서버가 세션 ID생성
4. 쿠키에 세션 ID저장 -> 브라우저의 쿠키에 세션 ID 넣어줌
5. 이후 요청 -> 이후 페이지에 요청할 때마다 쿠키의 세션 ID 자동 전송
6. 서버가 로그인 상태 확인 -> 세션 ID를 보고 로그인 했던 전적 확인

단점

• 서버에 저장해야 하기 때문에 서버 DB문제가 있을 수 있음

3) JWT 로그인

1. 로그인 요청 -> 사용자가 아이디와 비번을 입력
2. 서버 검증 -> 서버가 DB에 저장된 정보와 비교
3. JWT 생성 -> 서버가 JWT 토큰 생성 (사용자 정보 + 만료시간 + 서버 서명 포함)
4. 클라이언트 저장 -> 서버가 JWT를 사용자에게 전달
5. 이후 요청 -> 사용자가 요청할때마다 JWT 토큰 서버 전송
6. 서버가 검증 -> JWT 받아서 확인

단점

• 토큰이 탈취될 가능성이 있음

4) OAuth 로그인

1. 로그인 요청 -> 사용자가 “구글로 로그인”, “카카오로 로그인” 클릭
2. 인증 서버 이동 -> 서비스가 사용자를 구글/카카오 로그인 페이지로 보냄
3. 사용자 로그인 -> 사용자가 해당 서비스에서 아이디/비밀번호 입력
4. 인증 코드 받기 -> 로그인 성공하면 인증 서버가 기존 서버에게 임시 코드 전달
5. 토큰 요청 -> 기존 서버가 인증 서버에게 인증코드, 클라이언트 아이디, 클라이언트 시크릿 등 정보를 줌
6. 토큰 발급 -> 인증 서버가 확인 후 엑세스 토큰 발급
7. 사용자 정보 요청 -> 우리 서버가 토큰으로 사용자 정보 요청
8. 로그인 -> 처리회원가입 or 로그인 처리 완료

단점

• 외부 서비스 의존
• 코드 구현이 복잡함

2. 내가 채택한 방법과 구현과정

1) 내가 택한 로그인 구현방법

내가 채택한 로그인 구현방법은 "세션로그인"이다
그 이유는 다음과 같다.

1. 복잡성
   시험이 끝나고 시간분배를 잘 했어야 했는데 그러지 못하고 너무 오래 놀았습니다..... 시간이 없는 초보자가 그나마 안정적으로 성공할 수 있는 가능성이 보인 로그인 구현 방법이 세션로그인이라고 생각했습니다. 그래서 JWT, OAuth 보다 비교적 간단한 세션 로그인을 선택했습니다.

2. 기본기 이해
   JWT와 OAuth 모두 세션 로그인에서 비롯되어 발전된 구조이므로 세션 로그인 구조를 이해하면 나중에 다른 로그인 구조를 이해하기 훨씬 수월할 것이라고 생각하였습니다.

2) 게시판 페이지 구현

STEP 1. 기본 파일 실행시키기

문제점 1.

전주차에 구현했던 상품 목록 관리 파일이 날아가서 스프링부터 다시 깔고 처음부터 하고 있었다.😂
저번에는 404 NOT FOUND 에러가 나더니 이번에는 Whitelabel 에러가 떴다...
시간이 없어 일단 유튜브를 보며 설명을 따라갔다ㅜㅜ

저번처럼 실행하는 곳(?)이 잘못되었나 싶기도 했는데 강사님이랑 똑같이 Current file로 실행하는데 안되는 이유를 모르겠다ㅜㅜ

다른 부분을 하다보니까 저 problem이 자꾸 눈에 거슬려서 GPT에게 해결을 어떻게 하냐고 물어보았다.

그랬더니 Thymleaf 의존성이 없을 가능성이 있다고 해서 defendencies에 저 코드를 추가했더니

실행이되었다.....
되긴 했는데 어떻게 된건지 모르겠다 다음에 Whitelabel 에러가 또 떴을 때 해결할 자신이 없다 어떻게 된걸까..?? 난 분명 springBoot 파일을 다운받을 때 Thymleaf 기능도 추가했는데 왜 defendencies에 없었던 걸까

STEP 2. 글작성 화면 구현하기

HTML은 깃허브에 올라온 것을 복사해서 사용하였고 Controller는 강사님의 설명을 보고 따라치면서 기억나지 않는 부분을 복습하며 공부하였다.
다행히 이 부분에서는 막히지 않았다

문제점 2.

@Getter @Setter를 쓰려는데 어노테이션이 뜨지 않아서 강사님 영상을 확인하니 나는 롬북 어노테이션이 뜨지 않는다는 것을 발견했다.
이것도 Thymleaf와 비슷한 문제인가 생각이 들었다.

롬북도 Thymleaf와 마찬가지로 defendencies가 없었다. 이번에는 그래도 빠르게 GPT에게 물어보고 의존성을 추가했다.

STEP3. Maria DB 연동하기

https://www.youtube.com/watch?v=QRqWuJkpWRw&t=3s
https://www.youtube.com/watch?v=ZnxHLyu0Pso&t=213s
나는 위 두 동영상을 참고하여 Maria DB를 인텔리제이에 연동하였다.
저번과는 다르게 한번 해보아서인지 그래도 수월하게 할 수 있었다!!

yml vs properties

강의에서 application.properties를 application.yml로 바꾸었는데 강사님은 다른 DB를 쓰고 나는 Maria DB를 써서 안바꾸면 문제가 될까 싶어 properties와 yml 확장자의 차이를 알아보게 되었다.

• properies: 한 줄씩 key=value로 쓰는 방식

spring.application.name=demo
spring.datasource.driver-class-name=org.mariadb.jdbc.Driver
spring.datasource.url=jdbc:mariadb://localhost:3307/board
spring.datasource.username=root
spring.datasource.password=7470
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

• yml: 들여쓰기로 구조를 표현하는 방식

spring:
  application:
    name: demo
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost:3307/board
    username: root
    password: 7470
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
    properties:
      hibernate:
        format_sql: true

STEP4. 글목록 기능 백엔드 구현

Controller → Service → Repository → DB→ Repository → Service → Controller

먼저 DB에 있는 글목록을 꺼내 사용자에게 보이기 위해 Service에서 findAll을 사용하여 정보를 꺼냈다.

이후 DB에 저장되어 있던 Entity들을 DTO로 바꾸어주는 코드를 BoardDTO파일에 작성하였다.

DTO VS Entity

Repositiry는 주로 Entity 형태의 값을 DB에서 저장 및 삭제하고 Service는 Repository에게 받은 이 값을 DTO 값으로 바꾸어서 처리한다.
DTO와 Entity는 무엇이 다른 것일까?

- DTO(Data Transfer Object): 화면/요청/응답 기준 데이터

- Entity: DB 저장소 기준 데이터

예를 들어 사용자에게 보여주어야 할 정보가 아닌 것도 있을 수 있으므로 사용자에게 보여줄 정보는 DTO를 DB에만 저장해도 되는 정보, 민감한 정보들은 Entity를 사용하여 따로 DB에 저장할 수 있는 것이다.

마지막으로 Controller를 사용하여 목록 정보를 화면으로 보내는 코드를 작성했다.

STEP5. 글목록 기능 화면구현

여기서도 HTML은 깃허브에 올라와있는 코드를 복사해서 사용했다.

위와같이 게시판이 잘 작동되는 것을 확인할 수 있다.

다만 아직 조회기능을 만들지 못하였기 때문에 글목록에 들어가면 Whitelabel 에러메세지가 나타난다.

STEP6. 글조회 기능 백엔드 구현

Controller에서 id 값을 조회하고 Service에게 요청하면 Service가 Repository에서 Entity값을 DTO로 바꾸어 Controller에게 전달하고 COntroller는 그것을 HTML을 통하여 사용자에게 보여준다.

STEP7. 글조회 기능 화면구현

문제점 3.

백엔드 구현을 하고 HTML을 복사 붙여넣기 했을 뿐인데 글조회 기능이 실행되지 않았다.

HTMl이 잘못되었을리는 없어서 GPT에게 에러코드를 보여주었더니 Contrller에서 id를 넘겨주는 파람 어노테이션이 없을거라는 답변을 들었다. 그래서 파람이 있다고 화면을 보여주었더니 그 위에 줄 띄어쓰기가 잘못되어서 실행이 되지 않은 거였다.. 이걸 어떻게 알아

다행히 띄어쓰기 잘 고치고 글 조회기능을 만들 수 있었다.

STEP8. 글삭제 기능 백엔드&화면구현

Controller와 Service, HTML에 약간의 코드만 추가하면 되는 기능이므로 수월하게 구현할 수 있었다.
다른 정보 필요없이 id만 있으면 그 안에 들어있는 정보는 DB가 알아서 삭제해준다는 점이 신기했다.

STEP9. 글수정 기능 화면구현

STEP10. 글수정 기능 백엔드 구현

시간부족으로 아직 구현하지 못했습니다...............

3) 로그인 구현

STEP1. 로그인 기능 구조

• 회원가입:
  사용자입력값 -> MemberDTO -> Memverentity-> DB저장
• 로그인:
  사용자입력값 -> 이메일로 회원 조회 -> 비밀번호 비교 -> 세션 저장
• 로그아웃:
  세션 삭제

STEP2. Repository와 DB 접근 준비

JpaRepository를 상속받아 회원 저장과 조회 기능을 사용할 수 있도록 했다. 로그인할 때는 이메일로 회원을 찾아야 하므로 findByMemberEmail 메서드를 추가했다.


MemberEntity는 DB의 member_table과 연결되는 클래스로 회원의 이메일, 비밀번호, 이름 정보를 DB에 저장하기 위한 실제 테이블 구조 역할이다.

STEP3. 회원가입 기능 구현하기

흐름

http://localhost:8080/member/save 들어감
회원가입 폼 풀력
사용자 입력
MemberDTO 받음
MemberEntity로 변환
DB저장

회원가입 요청은 Controller에서 먼저 받는다. 사용자가 입력한 이메일, 비밀번호, 이름은 MemberDTO에 담기고, Service에서 Entity로 변환한 뒤 Repository를 통해 DB에 저장했다.

public static MemberEntity toMemberEntity(MemberDTO memberDTO)

화면에서 전달받은 DTO 데이터를 DB에 저장할 수 있는 Entity 형태로 변환하는 메서드

STEP4. 로그인 기능 구현하기

흐름

http://localhost:8080/member/login 들어감
로그인 폼 출력
이메일, 비번 입력
이메일로 DB 조회
비밀번호 비교
성공 시 세션 저장

로그인에서는 사용자가 입력한 이메일을 기준으로 DB에서 회원을 조회했다. 회원이 존재하면 입력한 비밀번호와 DB에 저장된 비밀번호를 비교했고, 일치할 경우 로그인 성공으로 판단했다.

Optional = null 에러를 줄이기 위해, 값이 있을 수도/없을 수도 있음을 표현하는 상자
findByMemberEmail의 결과는 회원이 없을 수도 있기 때문에 isPresent()를 이용해 회원 존재 여부를 먼저 확인하고 Optional로 값을받았다.

STEP5. 세션에 로그인 정보 저장하기

로그인 성공 후에는 HttpSession에 사용자의 이메일과 이름을 저장했다. 세션에 값이 저장되어 있으면 서버는 이후 요청에서도 해당 사용자가 로그인한 상태인지 확인할 수 있다.

Spring Security? HttpSession?

• HttpSession: 로그인 상태를 서버가 기억하게 해주는 저장 공간
• Spring Security: 로그인, 로그아웃, 권한, 보안 처리를 도와주는 큰 보안 프레임워크
  비밀번호 암호화, 접근 권한 설정, 관리자페이지 설정 등이 가능하다.

이번 프로젝트에서는 로그인의 기본 흐름을 이해하는 것이 목적이었기 때문에 Spring Security를 사용하지 않고 HttpSession을 이용해 직접 세션 로그인 기능을 구현하였다.

로그인 폼에서 입력한 이메일과 비밀번호를 Service로 보내 검증하고 로그인에 성공하면 HttpSession에 이메일과 이름을 저장하여 로그인 상태를 유지하도록 구현하였다.

STEP6. 로그아웃 기능 구현하기

로그아웃은 세션을 삭제하는 방식을 사용했다.
session.invalidate()를 호출하면 세션에 저장된 로그인 정보가 제거되므로 로그인 상태가 해제된다.

3. 느낀점 및 소감

오랜만에 하려니까 손가락이 영타치는 법을 다시 까먹은 것 같아요.. 제멋대로 움직이네여 손가락이..
저는 코딩레시피 2025 최신버전을 보고 과제를 했는데 최신영상이라 화면이 비슷해서 정말정말 편하고 좋았어요!!!!😍
강사님 화면이랑 바로 비교하고 어디가 잘못되었는지 확인이 가능하다는 게 너무 편했습니다..
프론트엔드를 예쁘게 만들고 싶은데 시간이 없어서 많이 알아보지도 못하고 코드 복사 붙여넣기만 해서 부끄럽네요 시간이 될때마다 조금씩 알아보고 수정하면서 벨로그에 업데이트 하도록 하겠습니다ㅎㅎ 시험기간이 한번 지나고 나니 이런 여유있는 시간이 너무 소중하게 느껴져요..
다들 시험보시느라 너무 수고하셨고 다시 열심히 해봐요!!🔥🔥