[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
at TCPConnectWrap.afterConnect as oncomplete
- redis 설치가 안되서 나오는 오류라고 한다.
secretOrPrivateKey must have a value
- jwt 토큰에서 비밀키가 없어서 나오는 오류
.env 파일을 사용중이었는데 팀원과 공유가 안됐었다.
설치법
https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-Window10-%ED%99%98%EA%B2%BD%EC%97%90-Redis-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0
블로그활용
jwt 토큰 쿠키 vs 헤더
Token을 쿠키에 저장하는 경우:
-
장점
- 보안성: 쿠키에 저장되는 값은 JavaScript에서 직접 접근할 수 없어서 일반적으로 안전합니다.
- 자동 관리: 쿠키는 브라우저에 의해 관리되므로 개발자가 별도의 관리 작업을 할 필요가 없습니다.
- 상대적으로 쉬운 구현: 쿠키를 사용하면 브라우저와 서버 간의 상태를 관리하기 용이합니다.
- 크로스 도메인 이슈 회피: 쿠키는 도메인 및 경로 설정을 통해 특정 도메인에만 전송할 수 있도록 제어할 수 있습니다.
-
단점:
- 오버헤드: 모든 요청마다 쿠키를 서버로 전송하므로 요청 크기가 증가하고 네트워크 트래픽이 증가할 수 있습니다.
- CSRF 공격 취약성: 쿠키를 사용할 때 CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있습니다.
AccessToken을 헤더에 저장하는 경우:
헤더에 저장하는 경우
-
장점:
- 작은 요청 크기: 헤더에 포함된 토큰은 쿠키에 비해 요청 크기를 증가시키지 않습니다.
- CSRF 공격 회피: 쿠키를 사용하지 않기 때문에 CSRF 공격에 대한 취약성이 줄어듭니다.
단점:
-
단점:
- 보안성의 취약성: 헤더에 포함된 토큰은 클라이언트 측에서 JavaScript를 통해 접근 가능하므로 XSS(Cross-Site Scripting) 공격에 취약할 수 있습니다.
- 수동 관리: 개발자가 헤더를 수동으로 설정하고 관리해야 합니다.
이 결정은 프로젝트의 보안 요구사항과 편의성을 종합적으로 고려하여야 합니다. 보안이 매우 중요한 경우에는 헤더에 저장하는 것이 좋을 수 있습니다.
CSRF 공격에 관하여 헤더에 유리한 점이 있는 것 같고, 보안과 편의성을 고려해 선택하면 될 것 같다