Projects25 SSL인증서 발급 받기 (Let's encrypt, certbot, ubuntu, ec2, spring boot) https://thiswooin.tistory.com/115 SSL인증서를 발급 받기 위해 도메인을 구매하고 이를 설정까지 마쳤다. SSL인증서를 발급받고, SSL? CA? SSL 인증서는 아무데서나 발급해주지 않는다. CA라고 불리는 인증기관이 있는데 여기서 발급받을 수 있다. https프로토콜의 과정 자체가 비대칭키를 활용하여 암호화와 복호화를 이루어내는데, 이 때 사용되는 비대칭키를 포함하여 안정성 있게 구현할 수 있는 회사가 선정된다고 한다. 그리고 우리가 쓰는 클라이언트에 이 인증기관들의 인증서에 대한 정보를 갖고 있다. Let's encrypt? Certbot? Let's encrypt는 CA 중에서 비영리 목적으로 무료로 인증서를 발급해주는 기관이다. 하지만 3개월마다 갱신을 해줘야하는 번거.. 2023. 11. 9. 도메인 등록하기, 네임서버 백엔드 서버의 SSL인증서 발급을 위해 도메인이 필요했다. 제일 저렴하게 구매했다. 그렇게 되면 이렇게 네임서버를 받을 수 있다. (다른곳의 네임서버 서비스를 이용해도 무관) 이제 아래의 요청 순서로 나의 IPv4 값을 얻어낸다. 나의 최상단 도메인은 shop이다. ICANN에서 shop 최상단 등록소의 서버 주소를 받아온다. DNS서버가 shop이라는 최상단 도메인에 example.shop을 물어보면 위의 네임서버를 알려준다. 그러면 네임서버에서는 나의 IPv4주소를 갖고있다가 이를 알려준다. 나의 주소 등록하기 내가 해야할것은 해당 네임서버로 접속했을 때, 나의 IPv4주소를 알려줘야한다는 것이다. 이를 위해 등록이 필요하다. DNS 관리 사이트별로 구성은 조금씩 다르지만, 맥락은 비슷하다. 해당 레.. 2023. 11. 8. [트러블] 서버 배포하기 - 쿠키가 생성되지 않는 이슈. (Same-site : none 설정) 문제발생 문제분석 1. 백엔드에서 jwt를 발급은 문제 없다. 2. 클라이언트에 Set-Cookie헤더가 잘 담겼다. 3. SameSite이슈로 Set-Cookie가 막혔다. 원인 분석 기존 로컬환경에서 백엔드 서버를 AWS EC2상에 올리자 클라이언트가 이를 Same-site로 인식하지 않게되어 쿠키 생성이 되지 않는다. 왜냐하면 Same-site=Lax로 기본값인데 이는 'safe'한 요청인 Get 메소드, , 의 접근만 허용한다. 그래서 이제 Cross-site로 인식되는 백엔드 서버로 오는 Set-Cookie가 작동하지 않음. 해결방법 응답을 Same-Site : None으로 설정해준다. 그러기 위해선, Secure를 설정해줘야한다. 그러기 위해선, SSL 인증서를 발급받아야 한다. 그러기 위해선.. 2023. 11. 6. 개인프로젝트 - 하하하 3 : 기본적인 보안. 쿠키, 로컬스토리지. + 리액트 렌더링 방식 1. 로그인 상태 유지 완료사항 유저정보를 로컬스토리지에 저장하여 헤더에 활용하는 등 이후에도 활용 예상. jwt를 쿠키로 저장해둠. (Access / Refresh) 고민하는 점 jwt vs Session 자체도 현재 의견이 많이 갈리는 듯하다. jwt를 쿠키 혹은 로컬스토리지에 저장하는 지도 의견이 많이 갈린다. 각각의 장단점이 다 있어보인다. jwt를 쿠키에 저장하고 RefreshToken을 httpOnly로 xss공격으로부터 기본적인 방어가 되어보이긴 하지만 이 역시도 완벽치는 않다. 우선은 jwt를 쿠키에 저장하고 RefreshToken을 rotation하는 방식으로 우선 개선해보려 한다. 2. 리액트 렌더링 App.js에 로컬스토리지로 부터 recoil atom에 값을 추가하는 코드를 useE.. 2023. 10. 23. 개인프로젝트 - 하하하 2 : 로그인 후 상태관리에 대한 고민 완료사항 회원가입기능 구현 완료 로그인 후 토큰값을 클라이언트에 쿠키로 저장 고민하는 점 - 로그인 된 상태를 전역적으로 어떻게 관리하는 것이 효율적일지 - 헤더바에 로그인 상태 표시하는 동작 구현 - 쿠키에 담겨있으니 이후 인증인가가 필요한 요청시에는 withCredential이 알아서 실려가는게 맞을지 - 'OO님 안녕하세요' 같은 문구를 위해선 로그인 시에 단순히 토큰만 가져오는 게 아니라 유저정보를 일부 가져와야하는 것이 맞을지. 기존 로직에 대한 변경이 필요할지 2023. 10. 7. 개인프로젝트 - 하하하 1 : 단순 CRUD부터 애자일하게 변경한 것 프론트엔드를 함께 구현하려고 하니 기본적인 CRUD에서부터 시간이 오래 걸린다. 그래서 완전 처음의 init브랜치에서 User정보와 로그인, 인증/인가 까지 구현하는 방식에서 다 덜어내고 기본 Quiz Entity의 CRUD만 구성하기로 했다. 현재 상황 라우팅, No CSS onClick동작하게만 구현 기본 CRUD 구현 느낀 점 - 프론트도 처음부터 차근히 하려니 더디지만 그동안 궁금했던 것들을 정면승부하는 느낌이라 좋다. 이제 유저정보와 이를 기반으로 인증/인가 구현 및 토큰관리 권한 설정등을 진행하려한다. 클라이언트 단에서 로그인 정보를 매 화면마다 어떻게 표현해야할지 아직 감이 오질 않는다. - 유저정보를 배제하고 먼저 기초적인 도메인부터 시작하길 잘한 듯 하다. - 테스트코드를 어떻.. 2023. 10. 4. 이전 1 2 3 4 5 다음
