아무것도 모르는 subray

넣으려는 데이터가 DB에서 Column 의 설정 된 길이보다 길어서 생기는 에러.

Column 길이 늘려주면 그만.

1. BCryptPasswordEncoder 방식

BCryptPasswordEncoder는 Spring Security 프레임워크에서 제공하는 비밀번호 인코딩 및 해싱을 위한 클래스입니다. 이 클래스는 BCrypt 해시 함수를 사용하여 비밀번호를 안전하게 암호화합니다.
BCryptPasswordEncoder를 사용하면 암호화된 비밀번호를 생성할 수 있으며, 생성된 암호화된 비밀번호는 암호 해독이 어렵기 때문에 보안성이 높습니다. 이는 사용자 비밀번호를 저장할 때 보안을 강화하고, 무단 액세스로부터 보호하기 위해 많이 사용됩니다.

2. DelegatingPasswordEncoder 방식

DelegatingPasswordEncoder는 Spring Security에서 제공하는 비밀번호 인코딩 및 해싱을 위한 클래스입니다. 이 클래스는 하나 이상의 PasswordEncoder를 사용하여 비밀번호를 암호화합니다. 주로 여러 가지 비밀번호 해싱 알고리즘을 지원하고자 할 때 사용됩니다.

의존성 추가

implementation 'org.springframework.security:spring-security-core:5.7.1'

내 생각

Spring Security 에서 가장 기본적인 암호화 클래스인 BCryptPasswordEncoder 가 기본이라고 생각하면 되고,

실제로 DelegatingPasswordEncoder 를 쓰더라도 사용자가 알고리즘을 명시해주지 않으면 기본 적으로 BCryptPasswordEncoder 로 선택 돼 사용 된다.

그치만 DelegatingPasswordEncoder 를 쓰는 이유는, 암호화 알고리즘의 변경이 필요할 경우 유연한 선택이 가능하기 떄문.

원인

- 로컬 브랜치가 원격 브랜치 보다 이력이 뒤쳐져 있어 발생 되는 문제

(Git이 익숙치 않아 솔직히 왜 최신의 로컬 브랜치가 원격 브랜치 보다 뒤쳐진건진 이해하지 못하겠다)

- 또는 원격 브랜치가 로컬 브랜치와 충돌하는 변경 사항을 가지고 있었을 경우.

(원격 브랜치에 적용 돼 있지 않았던 gradle 의 변경 사항 같은 것들이 로컬 브랜치에 존재 했는데 아마 이 때문이지 않을까 싶다. 앞으로 해당 문제가 재발생 된다면 다시 한번 두가지 문제를 고려해봐야겠다.)

해결 방안

- git push origin +main

우선 이렇게 '+'를 붙여 처리 했다.

지금이야 개인 프로젝트다 보니 간단하게 해결 했다만, 위의 명령어는 원격 저장소의 main 브랜치를 강제로 업데이트 하기 떄문에 일반적으로 권장 되는 방법은 아니다.

변경 사항을 강제로 푸시해야할 상황이 있어선 안되며 이러한 충돌이 있을 경우엔 충동 해결이 우선 돼야 한다.

(그러니까 차단기 떨어졌다고 그냥 올려 사용하지 말고 누전이나 또 다른 문제 해결이 우선시 된 후 차단기 올려 써라 이말)

1:1 관계에서는 외래키를 가진 Entity의 기본키를 참조하기 떄문에 referencedColumnName = "id" 는 따로 명시하지 않아도 된다. (물론 다른 column을 외래키로 쓸 경우 필히 명시해줘야 한다.)

Eager(즉시 로딩):

• 즉시 로딩은 연관된 엔티티나 컬렉션을 즉시 데이터베이스에서 가져와 메모리에 로드합니다.
• 즉시 로딩은 주로 연관된 데이터를 항상 함께 사용해야 하는 경우에 유용합니다.
• 예를 들어, 주문(Order)과 주문 상품(OrderItem)이 있을 때, 주문을 로드할 때 함께 주문 상품을 즉시 로드하면 주문 상세 페이지에서 주문과 주문 상품을 모두 표시할 수 있습니다.

Lazy Loading (지연 로딩 - FetchType.LAZY) 특징 :
연관된 엔티티가 필요할 때만 로딩되므로, 메모리 사용을 최적화할 수 있습니다.
하지만, 지연 로딩으로 인해 N+1 쿼리 문제가 발생할 수 있으며, 필요한 데이터를 로딩하기 위해 추가적인 데이터베이스 쿼리를 실행해야 합니다.

Lazy(지연 로딩):

• 지연 로딩은 연관된 엔티티나 컬렉션을 실제로 사용할 때까지 데이터베이스에서 가져오지 않습니다. 대신, 첫 번째로 엔티티를 로드할 때는 그 엔티티의 정보만 가져오고, 실제로 연관된 엔티티가 필요한 시점에 데이터베이스에서 추가적인 정보를 가져옵니다.
• 지연 로딩은 주로 성능을 향상시키고 불필요한 데이터베이스 쿼리를 줄이기 위해 사용됩니다. 예를 들어, 게시물(Post)과 댓글(Comment)이 있을 때, 게시물을 로드할 때는 댓글을 함께 로드하지 않고, 사용자가 댓글을 보려고 할 때만 필요한 댓글을 가져올 수 있습니다.

Eager Loading (즉시 로딩 - FetchType.EAGER) 특징 :
연관된 엔티티를 함께 로딩하므로, 관련된 모든 데이터에 대한 한 번의 쿼리만 실행됩니다.
하지만, 즉시 로딩을 사용하면 연관된 엔티티의 모든 데이터가 항상 로딩되므로, 데이터베이스 및 메모리 부하가 높아질 수 있습니다.
특히, 데이터 양이 많고 연관된 엔티티가 많은 경우, 즉시 로딩을 사용하면 응답 시간이 길어질 수 있습니다.

1. Header(헤더): JWT의 헤더는 두 가지 정보를 포함

(토큰의 타입을 포함, 보통 JWT)

• "alg" (Algorithm): 서명을 생성하는 데 사용된 해싱 알고리즘을 지정합니다. 일반적으로 HMAC SHA256 또는 RSA를 사용
• "typ" (Type): 토큰의 유형을 나타내며, 보통 "JWT"로 지정

2. Payload(내용): JWT의 페이로드는 실제로 전송하려는 정보를 포함합니다. 페이로드는 클레임(claim)이라고도 불리는 키-값 쌍의 집합으로 구성됩니다. 클레임은 세 가지 유형으로 나뉜다.

(사용자나 토큰에 대한 토큰 정보 포함, 예) 사용자 이름, 토큰 만료 시간 등) 

* JWT 토큰은 상태 또는 토큰에 대한 정보를 서버에서 관리 하지 않기 때문에 만료 시간을 꼭 넣어줘야 한다.
(서버가 아닌 클라이언트에서 관리 되는 JWT 의 특성상 유출 될 경우 보안에 문제가 생기기 때문에 만료 시간 지정이 필수 적이다.)

1. Registered Claims: 표준 클레임으로, 토큰에 대한 정보를 제공합니다. 일반적으로 이메일 주소나 발급자와 같은 정보가 여기에 포함됩니다.
2. Public Claims: 충돌을 피하기 위해 클레임의 이름을 URI 형식으로 지정합니다. 공개 클레임은 사용자 정의 클레임입니다.
3. Private Claims: 서비스 내에서 사용하기 위해 정의된 사용자 지정 클레임입니다. 이름이 충돌하지 않도록 URI 형식으로 지정됩니다.

3. Signature(서명): 서명은 헤더, 페이로드 및 비밀 키를 사용하여 생성됩니다. 서명을 사용하면 토큰이 변경되지 않았고(무결성 확인) 토큰이 발급된 곳에서만 생성되었는지 확인할 수 있다(인증).

(토큰이 유효한지 확인, 위조 되진 않았는지 ?)

이러한 구조로 JWT는 정보를 안전하게 전달하고 인증 및 권한 부여에 사용. 헤더와 페이로드는 Base64로 인코딩되어 있으며, 서명은 Base64로 인코딩되지만 비밀 키로 암호화되어 있다.