beMajor

Docker volume permission 문제 해결방법 (이 문서는 아티클을 참고해서 번역하고 정리한 글입니다.) (우리 프로젝트에 적용한 사례도 있습니다) 프로젝트를 진행하면서 도커로 컨테이너를 띄웠는데 log파일을 백업하기 위해 지정한 volume 디렉토리에 파일을 생성할 수 없는 오류가 있었다. 자꾸 권한이 없다고만 해서 권한을 777로 주니 되긴 하였으나, 이는 보안상 취약점이 될 수 있어서 다른 방법을 찾고 있었다. 찾던 도중 좋은 글을 발견하였고 초반부의 필요한 부분을 번역해보았고 이후 우리 프로젝트에서 어떻게 적용하였는지를 정리했다. 리눅스의 uid와 gid 도커 컨테이너 내에서 uid, gid가 호스트 시스템에서 어떻게 매핑이 되는지 아는 것은 안전한 시스템을 구축하는 데에 있어서 중요..

UnhandledPromiseRejectionWarning 문제(async,await의 예외처리) 웹소켓 서버를 리팩토링하면서 Error 클래스를 만들고 예외처리를 한 곳에서(errorHandler) 하도록 하고 있던 중 async 함수의 예외처리 중 자꾸 UnhandledPromiseRejectionWarning이 나타났다. 원인은 async 함수에서 예외를 던졌을 때 이를 catch하는 곳이 없어 나타난 것이었다. 그런데 나는 분명히 try, catch문으로 감싸고 있었는데 자꾸 이런 에러가 나타났었다. 왜 catch하는 곳이 없다고 하지? 우선 내가 작성했던 함수는 아래와 같다. errorHandler const errorHandler = (callback) => { try { return call..

jwt 스프링 서버에서 넘어온 jwt를 내가 시크릿키로 풀어보면 자꾸 invalid signiture오류가 났다. 계속 오류를 찾다가 스프링 서버의 코드도 찾아봤는데 아래 두 개의 메소드가 인자로 base64EncodedSecretKey를 String으로 받고 있는 것을 발견했다. Jwts.builder().signWith() Jwts.parser().setSigningKey() 그런데 현재 우리가 구현한 코드는 시크릿키를 base64로 인코딩하지 않고 넘겨주고 있었고 그래서 웹소켓서버에서 자꾸 유효하지 않은 시그니처 오류가 난 것이다. base64로 인코딩, 디코딩 했을 때 하나의 쌍은 있으나, 인코딩 하지 않은 문자를 디코딩했을 경우 쌍을 이루지 못한다. 따라서 스프링에서 Jwt를 만들 때는 꼭 시크..