JDBCTemplate 와 ORM 을 혼영할때, ORM을 못찾을 경우!

@EnableJdbcRepositories 으로 해당 인터페이스 클래스를 직접 정의해야함. (ORM 으로 자동 Class 주입을 하기 위해 찾지 못하는 듯)

@EnableJdbcRepositories(basePackageClasses = {BrandJdbcRepository.class, OrderListJdbcRepository.class, OrderJdbcRepository.class})

특정 Repositories 위치를 못찾을 경우

@ComponentScan 으로 해당 레포지토리 위치를 찾아줘야함.

@ComponentScan(basePackages={"ncode.domain.repository.boutique","ncode.domain.repository.brand", "ncode.domain.repository.order"})

ps. 해당 내용은 좀더 자세히 설명하려고 변경할 듯, 우선 해당 소스 삭제 전에 관련 내용 잊지 않기 위해 github upload

로그인 access_token

Post MAN 항목에 Tests 에 다음과 같은 스크립트를 삽입합니다.

pm.test("로그인 access_token", function () {
    var jsonData = pm.response.json();
    pm.globals.set("auth-token", `${jsonData.token_type} ${jsonData.access_token}`);
    pm.globals.set("auth-token-test", `${jsonData.refresh_token}`);
});

auth-token 이란 값에 실제 로그인한 토큰값이 삽입되어,

Authorization : 

로 자동 로그인한 헤더값을 사용할 수 있습니다.

취약점 요약

Apache Log4j 2.17.0 이전 버전은 LDAP JNDI 파서를 통해 원격 코드 실행 취약점이 발생합니다.
configuration, log message, parameter에 사용되는 Apache Log4j 2.0 Beta9 ~ 2.16.0 사이에 해당하는 모든 버전의
Log4j 2 JNDI 기능은 공격자가 LDAP 및 JNDI 관련 엔드포인트를 보호하지 않습니다.
Log message, 또는 Log message parameter에 접근하여 제어할 수 있는 공격자는 LDAP 서버에서 로드 된 임의의
코드를 마음대로 실행할 수 있으며, 사용자의 컴퓨터를 원격으로 조종할 수 있습니다.
Logj4 2.17.0 버전부터는 이 취약점을 사용할 수 없도록 업데이트 되었으므로 빠른 업데이트를 강력히 권장합니다.

취약점 영향

취약점이 발생할 수 있는 버전의 Log4j를 통해 신뢰할 수 없는 데이터 또는 사용자가 제어한 데이터 로그를 남길 때 해당 프로그램에 대한 RCE(원격 코드 실행) 취약점이 발생할 수 있습니다.
해당 취약점은 해커가 서버에 로그인한 것 만으로 사용자의 컴퓨터를 원격조종할 수 있기 때문에 심각도가 매우 높으므로 가능한 빠른 조치를 권고합니다.

영향을 받는 버전

Apache Log4j 2.0 Beta9 ~ 2.16.0 사이에 해당하는 모든 버전 및 Apache Log4j 2를 사용하는 제품은 모두 업데이트를 강력히 권장합니다.

제품 목록 확인하기

Log4j 1.x 버전은 이번 취약점에 직접적인 영향을 받는 버전은 아니지만,
제품 업그레이드 지원이 중지되었으며, 또 다른 RCE 공격 벡터에 노출되어 취약한 상태일 수 있으므로 가능하다면 2.16.0 버전으로 마이그레이션 할 것을 권고합니다.

마이그레이션 가이드

취약점 대응방안

이 취약점은 Log4j 2.17.0 버전 업데이트로 해결이 가능합니다.
Log4j 2.15.0 및 2.16.0 버전은 일부 환경 구성(macOS)에서 불완전하거나 JNDI Lookup 패턴 취약,
Lookup evaluation에서 무한 재귀 보호 불가 등으로 DOS 공격이 발생할 수 있는 여지가 존재하므로 반드시 최신 2.17.0 버전을 설치하세요.

업데이트 다운로드

Log4j 2.x 버전

Java 8 및 그 이후 버전을 이용중이라면 Log4j 2.17.0으로 업데이트 해야 합니다.
Java 7 을 이용중이라면 Log4j 2.12.2으로 업데이트 해야 합니다.

업그레이드가 불가능한 경우, 클라이언트 및 서버 측 컴포넌트 모두에서 시스템 프라퍼티 설정이 아래와 같이 되어있는지 확인하세요.

-Dlog4j2.formatMsgNoLookups=true

만약 Log4j 패치가 어려운 경우에는 다음과 같이 진행이 가능합니다.

버전 확인하는 방법

Log4j가 설치된 경로의 pom.xml 파일을 열어 log4j-core로 검색하여 version 확인 가능

버전 2.0-beta9 ~ 2.15.0

JndiLookup 클래스를 경로에서 제거합니다.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

버전 2.16.0

로깅 설정의 PatternLayout에서 Context Lookups를 ${ctx:loginId} 또는 \({ctx:loginId}처럼 스레드 컨텍스트 맵 패턴(%X, %mdc, 또는 %MDC)으로 바꾸세요. 혹은 설정에서 HTTP 헤더 또는 사용자의 입력과 같은 앱 외부 소스에서 발생하는 ${ctx:loginId} 또는\){ctx:loginId}와 같은 Context Lookups에 대한 참조를 제거하세요.

이 취약점은 Log4j-core JAR 파일에만 유효하며, log4j-api JAR 파일만 사용하는 앱은 이번 취약점과 무관합니다.
또한 Log4net, Log4cxx와 같은 Apache의 타 로깅 서비스들 역시 이번 취약점과 무관합니다.

작업한 방법

ext['log4j2.version'] = '2.16.0'

로 처리했습니다. 그리고 2.17.0 이 나왔다…고 합니다.

실제 서버에서는 2.15에서도 문제없는 상태라 우선 배제했습니다. 실제 서비스에서는 전부 logback 을 사용하여 문제가 없음.