기억하고싶은것들

설정 파일 분리 

application.yml을 사용하는 경우에는 "---"를 사용하여 설정을 분리할 수 있다.

server:
  port: 8089
spring:
  profiles:
    active:
    - test
  application:
    name: pj2
---
server:
  port: 8089
spring:
  profiles:
    active:
    - dev
  application:
    name: devPj2

또한, profile 단위로 설정 파일 자체를 분리할 수도 있다.

• application-dev.yml
• application-test.yml
• application-{profile}.yml

각각의 파일은 spring application을 실행 시 args 등으로 넘기는 spring.profiles.active로 결정되어진다. 

java -jar myApp.jar --spring.profiles.active=dev

여러 개의 설정파일 

하나의 profile에서 사용되는데 여러개의 설정 파일을 로드하고 싶은 경우가 존재할 수 있다.

이러한 경우에는 어떻게 설정하는지 알아보자.

spring.config.location

이 설정은 spring config의 기본 설정을 재정의하여 여러 가지의 설정 파일을 로드할 수 있다.

spring config에서 default로 제공하는 값은 아래와 같다.

사용자가 spring.config.location을 정의하면 default값은 덮어써지게 된다.

spring.config.additional-location

이 설정은 추가적인 위치를 설정하는 것이다.

location 설정에 플러스로 더 설정하고 싶은 경우 

spring.config.location, spring.config.additional-location 설정은 application.yml 파일을 로드하기 전에 사용되는 설정으로 해당 파일에 설정하면 동작하지 않는다.

SystemProperties나 CommandLine Argument로 전달해야 정삭적으로 사용될 수 있다.

java -jar myApp.jar --spring.config.additional-location=optional:classpath:test.yml

spring.config.import

해당 설정은 spring boot 2.4 이후부터 추가된 설정으로 위에 설명한 설정들과 달리 application.yml를 통해서 추가적인 설정 파일의 위치를 설정할 수 있다. 

spring:
  config:
    import:
    - optional:classpath:/test.yml

위의 내용들에 아래 spring문서를 확인하면 더욱 자세하게 확인 할 수있다.

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config

HandlerMethodArgumentResolver 란

HandlerMethodArgumentResolver는 Controller Method에서 특정 조건에 맞는 파라미터가 있을 때 원하는 값을 바인딩해주는 인터페이스이다.

Spring 공식 문서에는 아래와 같이 설명되어있다.

Strategy interface for resolving method parameters into argument values in the context of a given request.

주어진 요청으로부터, method의 parameter를 argument로 주입해주는 전략 패턴의 interface

Spring MVC를 작성할때, Controller에 정의한 Method들에도 @PathVariable, @RequestParam을 사용하는데 이러한 것들도 모두 HandlerMethodArgumentResolver를 구현하여 작성한 기능들이다.

Spring Example

위의 코드는 org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter의 코드로 Spring MVC에서 기본적으로 등록된 MethodArgumentResolver들이다.

간단하게 많이 사용하는 MethodArgumentResolver를 살펴보면 아래와 같다.

• PathVariableMethodArgumentResolver
  • @PathVariable
• RequestParamMethodArgumentResolver
  • @ReqeustParam

Custom HandlerMethodArgumentResolver 

@Controller
public class indexController{
    private final HttpSession httpSession;
    @GetMapping("/")
    public String index(Model model){
        User user = (User) httpSession.getAttribute("user");
        if(user != null){
            model.addAttribute("userName", user.getName());
        }
        return "index";
    }
}

위의 예시에서 HttpSession에서 부터 User를 가져오는 코드를 User가 필요한 모든 Controller의 Method에 작성하는 일은 중복 코드가 발생하고, 비효율적이다.

이러한 비효율성을 HandlerMehtodArguementResolver를 통해서 해결해보자.

HandlerMehtodArguementResolver

@RequiredArgsConstructor
@Component
public class LoginUserArgumentResolver implements HandlerMethodArgumentResolver { 
// 조건에 맞는 경우 메소드가 있다면 구현체가 지정한 값으로 해당 메소드의 파라미터를 넘길 수 있다
    private final HttpSession httpSession;

    @Override
    public boolean supportsParameter(MethodParameter parameter) { 
    // 컨트롤러 메서드의 특정 파라미터를 지원하는지 판단 
    // 파라미터 클래스 타입이 SessionUser인 경우 true 반환 
        boolean isUserClass = SessionUser.class.equals(parameter.getParameterType());

        return isUserClass;
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
            NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
            // 파라미터에 전달할 객체를 생성 

        return httpSession.getAttribute("user");
    }

}

여기서 사용된 SessionUser는 로그인시 HttpSession에 담아놓은 사용자가 정의한 User Class이다. 

HandlerMehtodArguementResolver 등록

@RequiredArgsConstructor
@Configuration
public class WebConfig implements WebMvcConfigurer { 
    private final LoginUserArgumentResolver loginUserArgumentResolver;

    @Override 
    // HandlerMethodArgumentResolver는 항상 WebMvcConfigurer의 addArgumentResulvers()를 통해 추가해야 한다 
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(loginUserArgumentResolver);
    }
}

Controller

@Controller
@RequiredArgsConstructor
public class IndexController {
    private final PostsService PostsService;
    // private final HttpSession httpSession;

    @GetMapping("/")
    public String index(Model model, SessionUser user) {
        model.addAttribute("posts", PostsService.findAllDesc());
        // SessionUser user = (SessionUser) httpSession.getAttribute("user"); 
        if (user != null) { // 세선에 저장된 값이 있을 때만 model에 userName을 등록해 준다
            model.addAttribute("userName", user.getName());
        }
        return "index";
    }
}

DTO 데이터 검증이 필요한 이유 

보통 Web Appliation을 작성하면, Front-End에서 사용자가 입력한 정보를 검증하고, 검증이 완료된 데이터를 Back-End에게 넘겨주게 된다.

하지만, 보통의 경우가 아닌 상황에서는 Back-End에서는 입력값으로 받은 DTO를 신뢰할 수가 없게 된다.

( Web Application UI를 통해 요청된 Request가 아닌 경우 - curl, postman 등등..)

이러한 상황에 대한 대비로 Back-End에서도 Request로부터 전달받은 DTO에 대한 검증이 필요하다.

@Valid

Spring에서는 DTO 필드에 조건과 메세지를 작성해주면, @Valid를 이용해 데이터 검증을 할 수 있다.

@Valid는 JSR-303, 380 표준 스펙으로

제약 조건이 부여된 객체에 대해 Beam Validator를 이용하여 검증하도록 지시하는 Annotation이다.

Spring에서는 LocalValidatorFactoryBean을 이용해 JSR 표준의 검증 기능을 사용한다.

SpringBoot 2.3 이상의 버전 부터는 spring-boot-starter-web 의존성 내부에 있던 validation이 사라졌다.

spring-boot-starter-validation 의존성을 따로 추가해 주어야 한다. 

Dto

@Getter
@NoArgsConstructor
public class UserSaveRequestDto {

    @NotBlank(message = "Please, insert UserID!")
    private String userId;

    @NotBlank(message = "Please, insert UserName!")
    private String userName;

    @Email(message = "Please, insert valid e-mail!",
            regexp = "^(?=.{1,64}@)[A-Za-z0-9_-]+(\\.[A-Za-z0-9_-]+)*@[^-][A-Za-z0-9-]+(\\.[A-Za-z0-9-]+)*(\\.[A-Za-z]{2,})$")
    private String email;

    @NotBlank(message = "Please, insert password!")
    private String password;

    @Size(min = 1, message = "User must be mapped with Group")
    @NotNull(message = "Please, insert GroupIdList!")
    private Set<String> groupIdList;
}

javax.validation.constraints에서 제공하는 valid 관련 Annotation 

https://docs.jboss.org/hibernate/beanvalidation/spec/2.0/api/

Controller

@RequiredArgsConstructor
@RestController
public class UserController {
    private final UserService userService;

    @PostMapping("/user")
    public String save(@RequestBody @Valid UserSaveRequestDto requestDto) throws Exception {
        return userService.save(requestDto);
    }
}

검증을 원하는 @RequestBody argument에 @Valid Annotation을 추가해 주면 된다.

Exception Handling

@ControllerAdvice
public class CommonExceptionHandler<T> {

    @ExceptionHandler(value = {MethodArgumentNotValidException.class})
    protected ResponseEntity<Response<T>> handleMethodArgNotValidException(
            MethodArgumentNotValidException exception) {

        Response<T> response = new Response<>();
        response.addErrorMsgToResponse(
                exception.getBindingResult().getAllErrors().get(0).getDefaultMessage()
        );

        return ResponseEntity.status(HttpStatus.NOT_ACCEPTABLE).body(response);
    }
}

@RequestBody로 부터 받은 파라미터에 Error가 발생한 경우에는 MethodArgumentNotValidException이 발생한다.

Spring의 Exception Handling 관련 Annotation을 이용하여 해당 Exception에 대한 처리를 추가해 주면 된다.

Spring Cloud Config는 비대칭키, 대칭키 각각 암호화/복호화 방식을 지원한다.

보안 측면에서 public key, private key가 각각 존재하는 비대칭키 방식이 더 안전하다. 

대칭키 방식은 암호화/복호화에 같은 키가 사용되므로 키가 유출됐을 때의 위험이 크다는 단점이 있다. 

비대칭키 생성 

// private key 생성
keytool -genkeypair -alias privateKey -keyalg RSA -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" -keypass "password123" -keystore privateKey.jks -storepass "password123" -storetype pkcs12

// 인증서 파일 생성
keytool -export -alias privateKey -keystore privateKey.jks -rfc -file trustServer.cer

// 인증서 파일 -> jks 파일 public key 생성
keytool -import -alias trustServer -file trustServer.cer -keystore publicKey.jks

Java Cryptography Extension (JCE) 설치

자바에서 제공하는 encrypt를 사용하기 위해서는 JCE 다운로드하여 classpath에 등록해주어야 한다. 

( 11버전 이후부터는 default로 포함되어 있다고 한다)

( https://www.oracle.com/java/technologies/javase-jce-all-downloads.html )

server - application.yml 설정 추가 ( for encrypt endpoint )

encrypt:
  key-store:
    location: file:../server/key/privateKey.jks # location of key 
    alias: privateKey
    password: password123

encrypt endpoint 

spring cloud config - properties example 

spring cloud config - properties 조회

위의 내용을 그림으로 표현하면 아래와 같다.

spring cloud server에서 encrypt, decrypt를 모두 담당하게 된다.

client에게 properties를 전달할 때 decrypt 된 값들을 전달하는 것이다.

Server-Encrypt, Client-Decrypt

위와 같은 형태가 아닌 server에서는 encrypt된 properties를 들고 있고

client에서 해당 properties를 가져갈때 decrypt 하고 싶은 상황에는 아래와 같이 설정하면 된다.

server - application.yml 설정 추가 ( for encrypt endpoint )

spring:
  cloud:
    config:
      server:
        encrypt:
          enabled: false
encrypt:
  key-store:
    location: file:../server/key/publicKey.jks # location of key 
    alias: trustServer
    password: password123

server side에서 decrypt 하는 것을 방지하기 위해 

spring.cloud.config.server.encrypt.enabled = false로 지정 

server side에는 encrypt만 담당하기 위해 public key 등록 

client-appliation.yml 설정 추가 decrypt

encrypt:
  key-store:
    location: file:../sba-server/key/privateKey.jks
    alias: privateKey
    password: 1q2w3e4r