오늘의 키워드

이메모 키워드

• 이건 메모 안하면 안될거야라고 생각한 키워드들을 적습니다

1

• 스프링 MVC와 Dispatcher Servlet
  Servlet
• 스프링 AOP와 PSA(Portable Service Abstraction)
• AOP와 POJO
  POJO
  AOP & PSA
• 본인인증
  XSS(Cross Site Scripting) 처리를 dispatcher servlet 단에서
  스프링 필터를 통해서 수행
  참조, 스프링 XSS 필터
  • 그냥 정규식이 아닌 Pattern.CASE_INSENSITIVE 등을 사용하는 방법
• dispatcher servlet 매핑
• 모바일 결제 방식
• 데이터 유효성 검증
  • 주민번호 digit 체크
• 비동기 통신 동작과 스크립트 호출, ajax

2

• 자바스크립트 Exception
  별도의 exception 로그가 남지 않음에 유념
  try-catch 문의 사용은 항상 exception을 생각하며 조심스럽게
• StringUtils
  문자열 다루기는 기본 중 기본
• 다음과 뒤로가기 로직
  뒤로가기는 기존 데이터와 페이지의 복구, 다음은 전달이 핵심
• 번호 저장과 체크박스 이벤트
• AES 256 암복호화
  • BASE 64 인코딩, AES 256 CBC
  • BASE 64 인코딩 패딩 = (이퀄 기호)
    BASE 64를 왜 사용할까?
• 패킷 사이즈 패딩
  TCP 패킷 통신에서 진짜 진짜 진짜 중요한 건 패킷 사이즈

3

• 제네릭과 Raw Type
• TypeSafety와 해결법(?)
• WeakHashMap
• 자바의 참조 방식
  • Strong
  • Soft
  • Weak
• JSON과 통신
  참고 링크
  • JSONObject
  • JSONArray
  • Map과 JSONObject
  • 한 줄 형태로 받는 JSONObject를 계층화 시키는 가장 쉬운 방법은??
• Http 라이브러리
  • HttpURLConnection
  • RestTemplate
    RestTemplate 설명
    커넥션 풀
  • WebClient(Spring 5, Spring Web-flux)
• 세션과 쿠키
  • 쿠키가 없어도 세션을 사용할 수 있을까?
• SSO(Single Sign On)
• @RequestBody와 Java Obejct Binding
  • Vo가 아닌 데이터들을 @RequestBody가 없이 데이터를 보냈는데
    계속해서 RequestMapping argument type mismatch 에러가 떴다.
    애플리케이션 내에서 API를 호출했기에 JSONObejct -> JSONObject로 보내는 상황 상 arguemnt type mismatch가 뜨는 상황을 이해할 수 없었음.
    하지만 @RequestBody를 붙이지 않으면 Java Obejct가 아닌 데이터들은 바인딩되지 않아 스프링이 데이터를 관리할 수 없음.
    하루동안 끙끙대던 문제였는데 정말 간단한 문제였다. 이거때문에 그러겠어라고 생각했는데 참 ㅎㅎㅎㅎㅎㅎㅎ

    @RequestBody
    @RequestBody는 Client가 전송하는 Json(application/json) 형태의 HTTP Body 내용을 Java Object로 Binding시켜주는 역할을 한다.
    HTTP Body가 존재하지 않는 Get method에 @RequestBody를 사용시 에러가 발생하게 된다.
    @RequestBody로 받는 Data는 Spring에서 관리하는 MessageConverter들 중 하나인 MappingJackson2HttpMessageConverte를 통해 Java Object로 Binding된다.
    @RequestBody는 Setter함수가 없어도 요청받은 데이터를 Binding할 수 있다.

• Http 문자열 인코딩과 패딩
  최신 브라우저와 Http Client 라이브러리들은 Content-Type에 의해 자동적으로 스프링이 String 데이터를 인코딩/디코딩 해준다.
  하지만 HttpURLConnection의 경우 스프링 Request로 인해 자동 인코딩은 되지만 이 사이에서 정확한 이유는 모르는.. 아무튼 문제가 발생하는데, 이 경우 별도로 보낼 때 인코딩 -> 받을 때 디코딩을 해줄 수 있어야한다.
  • Client Request 자동 인코딩
    node.js의 경우
  • RestTemplate 자동 인코딩
    RestTemplate의 경우
    RestTemplate의 경우 GET을 사용할 때 QueryParam이 자동 인코딩
    POST는 어차피 Response Body 담기기에 상관없는듯
  • x-www-form-urlencoded 자동 인코딩
    스프링의 경우
    헤더 정보는 단순히 정보지만, 스프링이 이걸 보고 urlencode 해준다.
    그래서 urlencode의 경우 별도의 인코딩을 신경쓰지 않는 것
  • 자동 패딩
    문자열 인코딩 후 자동 패딩(=)이 발생하는데 이걸 삭제해주지 않으면
    JSONObject 파싱이 불가능, StringUtils.removeEnd()로 삭제
  • 인코딩과 AES256
    AES256의 경우 암호화 과정에서 인코딩 이슈는 없지만
    복호화 과정에서 자동 인코딩 이슈가 있음. 기본적으로 + 와 같은 문자열이 공백으로 치환되기 때문인데... 이건 아직 잘 모르겠음
    복호화 과정에서 공백이 있으면 복호화 불가능하다.
    하지만 보낼 때 미리 java.lang.URLEncoder를 이용하여 인코딩 시
    공백치환이 발생하지 않는다.

6

• 스크립트 내장 함수는 id 요소만을 검색
• z-index 모달 z축 설정
• 자바에서는 html form 요소를 name으로만 매핑가능 (id는 자바스크립트를 위한 것)
• slf4j & lombok 이슈
  개발서버 세팅 중 받아온 프로젝트가 slf4j multiple binding 에러가 나옴. lombok의 경우 따로 import 에러는 없지만 어노테이션 미동작
  • 해결 : 알고보니 별도의 에러는 안뜨지만 롬복 jar이 빠져있었음
    특이한게 롬복 이슈를 해결하니 slf4j multiple binding 문제도 해결
    (원래 롬복 이슈 해결로 풀리는 게 아니라면 exclusion 태그를 사용해서 바인딩 하나는 제외 시켜줘야 함)

7

• 패키지 내 특정 파일만을 변경하고 컴파일하고 싶었음
  하위호환성을 위해 단 2줄만이 추가됐는데 패키지 전체를 컴파일 해야하나 싶어 각고의 노력을 쏟은 결과
  • 결론적으로 패키지 전체를 컴파일해야한다
  • 컴파일 시 인코딩 변환은 javac -encoding utf-8