문제상황 Ubuntu 기반 VM 서버 위에 스프링 부트 프로젝트를 배포했다. 로컬에서 8080 포트로 개발을 진행하던 프로젝트였는데, 배포 후 테스트를 해보니 요청이 8080 포트로 전달되지 못했다. 따라서 디폴트 포트인 80번으로 요청을 보내서, 해당 요청이 8080 포트로 리다이렉트 되도록 포트포워딩을 시켜주기로 했다. 해결 과정 > 저는 해당 현상을 포트포워딩을 통해 우회적으로 해결했지만, 조금 더 찾아보니 애초에 우분투 자체 방화벽에서 8080 포트를 열어줬어야 하는 것으로 보입니다. 아래와 같이 iptables 명령어를 통해 특정 포트를 열어줄 수 있습니다. 기본적으로 클라우드 자원 위에 서버를 올리게 되면 `http://인스턴스에 할당된 외부 IP or 도메

문제 상황 Organization에서 작업하는 레포긴 했지만 백엔드 팀원이 나뿐이라 혼자 작업하고 있었고, 따라서 master 브랜치에서 모든 작업을 하고 있었다. 이때 API 서버를 배포하는 과정에서 git에 올라가면 안될 파일이 올라갔다. .gitignore에 해당 파일을 추가하고 캐시를 삭제해서 다시 커밋했지만, 커밋 이력에는 여전히 해당 파일의 정보가 남아있는 상태. 해결 방법 최신 커밋은 유지하면서, 해당 정보가 포함된 커밋만 삭제하고 싶었다. 따라서 rebase를 이용해 중간의 특정 커밋들을 삭제하여 해결했다. Rebase? > 리베이스는 변경사항을 별도의 patch로 만들어 저장해뒀다가, base가 될 브랜치에 순서대로 적용하는 방식으

문제 상황 Organization 레포를 개인 레포로 포크해서 커밋 후 Pull Request (이하 PR) 을 날리는 방식으로 운영되고 있었다. 그런데 어제 PR만 날려야 하는 상황에서 실수로 Auto Merge를 시켜버린 상황. 해결 방법 Revert Github PR 페이지 내에 활성화된 Revert 버튼 클릭 후 내역 PR (Revert 버튼을 클릭하고 이어지는 버튼을 그대로 클릭하면 된다.) > Revert 후 다시 PR을 시도했더니 conflict가 발생해서, PR에 해당하는 커밋 내역을 개인 레포에서 아예 지워준 후 새로 커밋해서 PR을 해보기로 했다. PR 날렸던 Commit 삭제 변경사항을 다른 곳에 백업해두고 변경에 해당하는 내역을 지워주거나 파일 삭제 개인 레포로 돌아와 git log -oneline으로 PR을 날렸던 커밋의 부모 커밋 번호 확인 git reset --hard {커밋 번호}

JWT 발행 API를 테스트하던 과정에서, 네트워크 응답 상에는 헤더에 Authorization이 오는데 프론트로 보낸 응답을 콘솔에 찍으면 나타나지 않길래 이유를 찾다가 원인을 발견했다. 💡 헤더 Authorization 항목은 서버 CORS 설정에서 명시해주어야 한다 WebConfig는 서버 측에서 CORS 이슈를 피하기 위해 설정한 Configuration이다. 구글링을 해보며 본 바로는 CorsFilter를 사용하는 경우가 더 많았지만 나는 Configuration에 설정하는게 편해서 이렇게 했다. 여기서 .exposedHeaders(””) 부분을 그냥 “”로 퉁쳐서(?) 해결하려고 했는데, 프론트와 통신을 시켜보니 프론트에서 받아온 response를 콘솔에 찍으면 authorization 항목이 보이지 않는 현상이 발생했다. ![](https://velog.velcdn.com/images/codesusu