[Pre-Project] Day 13 : 헤더로 토큰 전달, 배포(실패😭)

프로젝트를 하는 과정에 있어서 기록하는 것이다.

본 글은 오늘이 마지막이다.

---

✅ 헤더 토큰 전달

• JWT로 로그인을 구현한 후, 헤더로 Authorization과 Refresh Token을 전달하려고 했다.
• 그런데 헤더로 전달이 안되는 것...
• 그래서 찾아봤더니 해당 키는 따로 또 설정을 해줘야 한다고!!
• CORS 필터에 아래 두 코드를 추가해주었다.
• 아래 링크를 보고 알게 되었다.
• 참조 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers

configuration.addExposedHeader("Authorization");
configuration.addExposedHeader("Refresh");

• 그래서 이렇게 추가해주었더니 헤더로는 전달이 잘 되었다.
• 하지만 프론트 분과 상의한 결과 Cookie로 받아보기로 했다.
• 처음엔 아무리 바꿔도 Cookie로 접근하면 401 에러가 나는 것이다..
• 근데 회의하면서 바꿔봤더니.. 왠걸 바로 해결...
• 아래처럼 받는 헤더를 Cookie로 바꿔주고, 시작을 Authorization=Bearer로 바꿔주었다.
• 이렇게하니 바로 해결이 되었다.... 하지만... 하지만... 하지만........!😭

@Override
protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
	// String authorization = request.getHeader("Authorization");
	String authorization = request.getHeader("Cookie");

	// return authorization == null || !authorization.startsWith("Bearer");
	return authorization == null || !authorization.startsWith("Authorization");

}

private Map<String, Object> verifyJws(HttpServletRequest request) {
	// String jws = request.getHeader("Authorization").replace("Bearer", "");
	String jws = request.getHeader("Cookie").replace("Authorization=Bearer", "");
	String base64EncodedSecretKey = jwtTokenizer.encodeBase64SecretKey(jwtTokenizer.getSecretKey());
	Map<String, Object> claims = jwtTokenizer.getClaims(jws, base64EncodedSecretKey).getBody();

	return claims;
}

---

✅ AWS EC2를 이용한 배포

• 이제 배포만 남았다.
• 로컬에서 연결이 잘 되었고, CRUD가 잘 해결되었다.
• 하지만 ... EC2에 연결하니 문제가 발생하였다.
• 같은 경로가 아니라 쿠키로 Authorization을 요청 받을 수 없었고, 그래서 모든 권한을 열었다.
• 그럼에도 불구하고 계속해서 404 에러가 발생하였다.
• 진짜 status만 404 뜨고 message도 fieldError도 violationErrors도 아무것도 나오지 않았다...
• 아래의 에러만 약 한시간 넘게 해결을 못했다...

{
    "status" : 404,
    "message" : null,
    "fieldErrors" : null,
    "violationErrors" : null
}

 

• 수정을 하면 할 수록 에러는 해결이 되지 않고, 이제는 아예 필터에서 걸러져 해결이 되지 못했다.
• 너무 웃긴건 PostMan으로 데이터를 보내면 잘 들어가진다는 것....!

• 현재 이 글을 쓰는 새벽 1시 반... 한시까지 정말 이것 저것 다 해보고 노력해보았으나 해당 에러를 해결할 수 없었다.

---

🥲 해본 것들

• SecurityFilterChain에서 anyRequest.permitAll()을 제외한 모든 authorizeHttpRequests를 주석처리하였다.
• corsfilter에서 아래처럼 상세하게 해보았다. 
• 그래도 해결이 되지 않았다.

configuration.addAllowedOriginPattern("백엔드주소");
configuration.addAllowedOriginPattern("프론트엔드주소");
configuration.addAllowedOriginPattern("S3 버킷 주소"); X 3(포트 포함 2개, 포트 미포함 1개)

• 크롬의 문제일까 싶어 아래의 코드도 입력해보았으나 역시 실패..

open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome —args —user-data-dir="/tmp/chrome_dev_test" —disable-web-security

• 그렇게 여러번 시도하고 수정하고 시도했으나, 결국에는 배포하지 못했다..
• 너무 아쉬운 결말이다..
• 프론트 팀원 분들이랑 백엔드 팀원분들이 정말 정말 고생하셨는데..
• 계속해서 무언가 걸리는게 Security인 것 같아서 마음이 조금 더 무거운 것 같다.. (내가 한 파트다 보니)

---

🙃 어찌쩌지 프리 프로젝트를 마무리하며

: 처음에 프리 프로젝트를 들어갔을 때 걱정이 정말 많았다. 내가 제대로 겉으로만 배우고 정말 알맹이가 없다고 생각했기 때문이다. 진짜 그랬다. Security를 구현하면서 해당 필터들이 어떻게 작동하는지 잘 몰랐다. 그래서 하나하나 찾아가면서 보고, 흐름을 이해하려고 노력했다. 솔직히 지금도 내가 만들지 않고 시큐리티 필터에서 자동으로 걸러주는 것들은 잘 모르겠다. 여러번 읽어도 이해가 되지 않았다. 그래도 내가 직접 만들어본 핸들러나 필터들은 그래도 다음에 한 번 더 해보면 전보다는 흐름을 이해하면서 하지 않을까 생각이 된다. 왜냐하면, 단순히 클래스에 있던 내용들을 따라한 것이 아니라 계속해서 바꿔가면서 했기 때문이다. 그래서 조금은 처음보다는 발전하지 않았나 하는 생각이 든다. 그럼에도 불구하고, EC2에서 배포가 안된건 너무너무 아쉽다. 특히 해당 문제가 시큐리티부터 안되는 것 같아서 마음이 많이 무겁다. 다른 팀들의 코드를 찾아보았다. 해당 코드가 크게 다르지 않았다.. 도대체 뭐가 원인인 걸까... 너무 답답하고 알고 싶다...😭

   그래도 처음 프리를 들어올 때보다는 배워간 게 많은 2주였다고 생각한다. 처음 해보는 프로젝트고 사실 제로 베이스로 시작한 내가 4개월만에 무슨 기능을 구현한다는 게 말도 안된다는 소리라고 생각했다. 그런데 어찌저찌 하다보니 어느새 무언가 하나씩 구현되고 내가 하나씩 전보다는 부딪혀가며 배우다보니 조금 더 찾아보게 되고, 전보다는 알맹이를 보려고 노력한 것 같다. 사실 에러를 하나 만날 때마다 진짜 스트레스도 받고 우울하기도 하고.. 몇 시간씩 에러를 보다가 울컥하기도 하고 진짜 감정이 역대급으로 왔다갔다한 이주였다. 아무래도 잘하고 싶다는 욕심이 너무 컸던 것 같다. 그럼에도 정말 행복했던 순간들이 있다. 몇 시간씩 안되던 에러를 해결했을 때, 그 순간에는 너무 행복했다. 특히 해당 에러를 내 힘으로 스스로 찾아서 해결할 때는 정말 뿌듯함과 감격이 엄청 났던 것 같다. 그게 지금까지 버티고 도전해보게 한 것 같다. 아무튼 나 자신 매우 수고했고, 그치만 모자랐고 더 잘해라 😃